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I. INTRODUCTION 



A. INTRODUCTION 

Much has been written of the promise of virtual worlds (VW) technology. However, very little has been 
published on the implementation of such systems. And what has been published has shown a remarkable en- 
amoration with the hardware and not with the enabling software. This dissertation deals almost exclusively 
with the software aspects of a VW system developed at the Department of Computer Science, Naval Post- 
graduate School (NPS). We have named this system the Naval Postgraduate School’s Networked Simulator 
or NPS NET for short [ZYD A9 1 AJZYD A92] . 

In NPSNET, we have identified some of the salient characteristics and challenges faced in the construc- 
tion and management of VW systems. On identifying these characteristics, we were able to construct a frame- 
work which we have successfully used as a test bed for exploration of our ideas and proposed solutions. These 
ideas have included, but are not limited to, network management, dynamic terrain 1 , vehicle dynamics, paging 
terrain databases, and terrain database construction. 

There is a considerable amount of publication on VWs in both the popular and academic press lately. It 
has gotten difficult to open up a magazine without an article on or advertisement for a VW system. VW sys- 
tems are also known as Virtual Reality (VR), Artificial Reality, Synthetic Environments, Cyberspace, or 
Real-time Interactive Three Dimensional Computer Graphics fRHEI91 1. Several of these terms have come to 
have a negative connotation due to their over use and hype. Almost every program that uses computer graph- 
ics claims to be a VW system, usually by a marketing person trying to hype the system. With articles in the 
popular press warning us of the sociological implications of VW systems and the hype from the marketing 
force, VW is in real danger of becoming the Artificial Intelligence (AI) of the 90’s. Much like AI, the field is 
in its infancy. The ground breaking work has been done and many people can see the potential, but major 
work still has to be accomplished. One crucial component is the integration of and documentation of the com- 



1. In this dissertation terrain and terrain database are meant to include all fixed entities. This 
includes cultural features, such as buildings, roads, and bridges, as well as vegetation, such as trees, 
crops, ground cover. 
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ponent processes of a sample implementation. That is the main thrust of this dissertation, how a virtual world 
system can be constructed on a low cost commercially available graphics workstation. 

B. DEFINITION OF VIRTUAL WORLDS 

Before we go much further, we need to establish a good working definition of what a VW is and what 
it is not There are a myriad of definitions depending on where you look and what the author wants to convey. 
Each of the texts, [BENE92], [GELE91], [HAMI91], [HELS90], [RHEI91] and [KRUG91], has its own 
slight twist on it. Even a Senate hearing, [USS91], and a business survey, [MILL92), have failed to come up 
with a universally accepted definition. But there are some common elements in all of them. In the paper that 
first hypothesized about VW, Ivan Sutherland calls the ultimate display one that provides us with an interac- 
tive window on the world [SUTH65]. That captures the fundamental and accepted aspects of a VW. It is a 
world transposed in time or space, either real or imagined, that the user can interact with in real-time. 

Humans are cultural creatures; we live and function best in a populated environment We look around 
and see things, the players 2 in the world. When we interact with these players, they exhibit some degree of 
autonomy, they react to the environmental stimuli. Different types of players respond in different ways to the 
stimuli. Assume we are approaching an icon in the VW. If it is a wall, it will just stay there and prevent our 
movement. If it is an icon representing a small furry creature, it might scurry away. The world that we live in 
is not just made up of static objects, such as the wall, but also, and perhaps more importantly, of a collection 
of the players we encounter, the small furry creatures. Together the wall and the creature, and all the other 
objects, make up the population of the VW. 

The physical properties of the real world can be rigorously applied and be the main reason for the 
world’s existence, as in [LEVI92] and [BROO90]. Or reality can be fanciful and real physics has no bearing 
on the design or interaction, as in [BUTT92J and many of the worlds constructed by VPL. The interaction 
with the world can be accomplished on several different levels, but the key is to immerse the user in the world 
so that the user is literally sucked into the experience. Some believe that in order to immerse the user in a VW 
system you need to have a Helmet Mounted Display (HMD) and a DataGlove. Others, the author included, 
contend that it can be done by reading a good book with some imagination. While the book may give the user 

2. Throughout this dissertation, we use the term player to mean any entity capable of interaction in 
the virtual world. This entity may be a real person interacting with the system locally or via a net- 
work or a computer controlled thing used to populate the world. The term user is reserved exclu- 
sively for the human player. Ideally, there should be no apparent distinction between the two, sort 
of a VW Turing test. 
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a sense of presence, it fails miserably in the interaction axis. Zeltzer has developed an Autonomy-Interaction- 
Presence cube that places VW at the (1,1,1), maximum along each of the axes [ZELT92]. 

In summary, a VW system can be characterized by being a bidirectional, highly interactive populated 
world transposed in time or space and the physical rules that govern the real world may or may not apply. 
NPSNET has not solved all the issues in developing a complete VW, but we have made significant strides in 
that direction. 

C. OVERVIEW OF PROBLEM 

The state of the art in VW is limited to a few simple players with simple interaction in a simplistic world. 
Very often, it is a single user flying around and the only thing he can do is lode at the world. The interactivity 
in that type of system is only slightly higher than reading a book. The systems that do support multiple users 
use expensive special purpose hardware and software. This hardware and software is unavailable to all except 
a few select military projects. 

The problem then becomes how can a VW be created and maintained*. The literature has a few exam- 
ples of how the hardware components can be connected to build such a system, or how to use commercial 
software to construct limited worlds but in both cases, the enabling software is skimmed over or hypothesized 
[BENE92] [GELE91] [HAMI91] [HELS90] [RHEI91] [KRUG91]. Likewise, there is an abundance of re- 
search on how to do a small component in isolation (BADL91] [ZELT89B] [BROO 88 ]. What is lacking is 
some unifying methodology to connect all the various parts together into a single coherent virtual world, sort 
of a Stephen Hawking of Virtual Worlds. That is the goal of this dissertation, to build and document a highly 
interactive, extensible virtual world. In order to do this, the component research and the overview documents 
have to be merged into a single working system. 

D. GOALS AND MOTIVATION 

As with all research, this project has certain motivations and goals behind it. In this section we briefly 
discuss some of the goals of the research and our motivation for those goals. 

1. Goals Of Research 

Our goals for this research were simple: 



3. As the user interacts with the VW, certain portions of the world can change. An example of this is 
the addition of a crater where a missile hit. The maintenance of the VW is the management of the 
modification of the VW database that occur at run-time, such as the placement of the crater. 
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Build and operate a complex and highly populated virtual world. 

Construct a modular framework for interaction with the virtual world. 

Provide multiple user interaction in the shared virtual world. 

Use commercially available graphics workstations as the world generator. 

As it turns out in many cases, goals that are simple tend to be over simplifications. The first goal 
required that we have many players in the world each doing their own thing, but interacting with the other 
players. It also required that there be a multitude of interaction capabilities and a complex environmental da- 
tabase or playing field. To a large extent, the second goal was contradictory with the rapid fulfillment of the 
first. It is much harder to develop an efficient generic framework than it is to solve a particular instance. But 
we knew that this system was going to be used for many different purposes, so it had to be modular and flex- 
ible. The third goal was that of providing a mechanism where more than one user could interact in a shared 
data space. This required the actions of one user to be visible to the other users and have them affect the shared 
world equally. The rationale for this was that humans are social creatures and we enjoy interacting with each 
other, via whatever medium. The goal of using commercially available workstations required the develop- 
ment of quite a few of the routines that high-end flight simulation systems have embedded in hardware. Such 
systems are documented only in internal, corporate proprietary reports that are not generally available. By the 
same token, the embedding of the routines in hardware limits the flexibility of the systems. Such hidden and 
task specific work does not contribute to the general development of accessible VWs. 

2. Motivation 

The goals of this research are noble, but they are well motivated by what we perceive as funda- 
mental requirements. The first and foremost motivation was to lower the cost of entry into a multi-player en- 
vironment. In 1991, the price of a virtual world system was estimated at approximately $250,000 [USS91]. 
Other systems ranged in price upwards of $350,000 for a SIMNET network node [IDA90]. Clearly, this is 
not the price that many institutions, much less private individuals could afford. By using commercially avail- 
able workstations, in this case the S ilicon Graphics Inc. (SGI) IRIS 4D line, the cost of hardware development 
is amortized over the mass market, rather than limited to a few special projects. Also, it is in the vendor’s best 
interest to continue the hardware development to ensure its competitive position in the market place. This 
frees us up from the role of hardware developer and allows us to focus on the enabling software. 

It has been well documented that humans are three dimensional (3D) visual creatures. Fred Brooks 
and Tom Furness have proven over and over during their careers that users understand better and are able to 
grasp new concepts better when they are presented in 3D [BR0088][USS91]. Combat is, by its very nature. 



4 



three dimensional. Both sides are constantly looking to use the terrain to their advantage and to deny any ad- 
vantage to the enemy. In order to gain a better understanding of the terrain where a battle will be fought, it is 
standard practice to build a small 3D sand table of the terrain to aid in the visualization. However, due to the 
processing requirements, most of the Constructive Combat Models (Janus and BBS for example) are strictly 
two dimensional (2D) [TITA93] [CECO90). The lack of a 3D representation of the terrain has lead to some 
obvious tactical errors when scenarios are being set up. This in turn, has lead to the discounting of some of 
the simulations results. Also, certain physical impossibilities, such as the physical colocation of two entities, 
are not even considered by the model. If the scenario designers had a 3D representation of the terrain available 
to them during the construction of the engagement, they could place the entities in more realistic locations. 

[GARV88] and [KRAU91J proved that VWs can serve as a valuable training and research and de- 
velopment tool. However, this is only true if the students and the developers can get access to the VW systems 
in a timely and cost effective manner. This historically has not been the case. There have been only a few 
expensive systems which have been available and these systems have been dedicated to particular applica- 
tions. In order to increase the benefit of VWs, the systems themselves must become more pervasive. In this 
era of shrinking dollar, this will only happen if the systems are inexpensive and flexible enough for the users 
to procure. After all, if the training and testing equipment is not cost effective it makes no sense to do it. 

Finally, we have seen a lot of good research going on without a true sense of the bigger picture. 
Brooks’s view of the computer scientist as a toolsmith is a valid one [BROO 88 ]. There is no way that some- 
thing can be constructed until the tools have been built. Yet there is a time when you must shift the emphasis 
from building the tools and start construction of the major system. Many of the components of VWs are al- 
ready here, or being worked on. It is time now to start the construction of a meaningful VW. 

E. PROBLEM DOMAIN BACKGROUND 

The focus of this dissertation has been on the iterative development of a flexible and expandable VW 

test-bed A ground combat world was chosen as a test-bed system for the following reasons: 

Highly Interactive World — both User / Computer and User / User Interaction 
Populated Environment - both Moving Vehicles and Static Objects 
Demanding Graphical Requirements 
Dynamic Database Requirements 
Available Terrain/Object Databases 

Real World Application with Large Amount of Subject Area Expertise Available Locally 

Ground combat is the action of bringing two or more opposing land based armed units together for an 
engagement where one side tries to destroy the other. The armed units can be as simple as a single individual 
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or as complex as a full fledged corps, in excess of 100,000 men and vehicles. Combat by its very nature is 
highly interactive. Each side is constantly trying to maneuver into a position of advantage over the other while 
expending a minimum amount of resources. As such, the units are forced to react to each other and to the 
underlying terrain. When the engagement becomes computerized, the users are forced to interact with the 
computer that acts as a mediator in the engagements. In addition to its role as mediator, the computer is also 
responsible for modeling the world state and ensuring only valid actions take place. It is this interaction that 
forces Zeltzer’s Interaction point value close to one. 

With the exception of a few types of engagements, such as sniper fire, most of the engagements have 
multiple players on each side. The number of players in the engagement demands die system to be well pop- 
ulated. Yet, very often the resources are not available for each player to be controlled by a human controller. 
As such, autonomous players controlled by the computer must be introduced into the VW. These players 
should behave in a manner consistent with their manned counterparts. One of the many interesting aspects of 
ground combat is that not only do the vehicles, or dynamic players, interact with each other but with the static 
entities on the database as well. The static entities include things like buildings, trees, etc. These are things 
that do not move during the course of an engagement but might undergo a change of state and can influence 
the outcome of an engagement. For example, a building might block the line-of-sight between two players 
until it is destroyed at which time the two players can then interact Thus, there has to be a high level of au- 
tonomy in the computer controlled players. 

Over the years, the range of ground combat weapons has increased dramatically. However, the under- 
lying terrain has not changed all that much. As a result, most of the engagements that use line-of-sight weap- 
ons are limited by the terrain to approximately 3500 meters or less [GARV88]. Even this small distance 
requires that forty-nine square kilometers of data be available for immediate rendering. In order to ensure a 
sense of presence, the terrain has to be of sufficient resolution to capture the critical features of the environ- 
ment and yet coarse enough to be rendered in real-time. This is the classic trade-off of quality versus speed. 
Not only does the database have to be of high quality, but it must be able to be modified over time. As an 
engagement proceeds, the underlying terrain can, and normally does, undergo a significant modification, such 
as shells landing and leaving craters or a berm being built. Users who have been in combat know how to ex- 
ploit these modifications to their advantage and expect to see the terrain database be modified. If the terrain 
is not rendered at a fast enough frame rate, if it is too coarse, or if does not respond to events, the user’s sense 
of presence approaches zero. This requirement puts a very heavy load on the graphics system. 
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Due to the nature of NPS, we had ready access to terrain and entity databases. This allowed us to focus 
on the development of the software rather than on the geometric modeling of the world. Also, since virtually 
all the students at NPS are United States military officers, we had a ready pool of task area experts who could 
serve as a validation reference for the models and designs we constructed. Unfortunately, ground combat is 
a real world problem and promises to continue to be for many years to come. Therefore, the modeling and 
representation of ground combat is a useful and practical problem. Just like University of North Carolina - 
Chapel Hill chose three topic areas to ground their research in reality (Architecture, Molecular Modeling, and 
Radiation Therapy) we have chosen ours in a field where the our resources and task experts are available 
[USS91]. 

F. ORGANIZATION OF CHAPTERS 

The body of this dissertation is broken down into three main sections. The first of these sections is the 
introduction. First, we present an introduction to the concepts, definitions, and motivation of our research. 
Chapter I. The second part of the section contains a description of the challenges faced by the virtual worlds 
researcher. Chapter II. The third chapter. Chapter III, of this section contains a description of a few of the 
major virtual world systems. 

The second section covers the NPSNET system. Chapter IV introduces and gives a brief overview of 
NPSNET. Originally, NPSNET was a VW designed to simulate ground combat As such, the terrain database, 
which in this case is the world database, is extremely important to the performance of the system. The con- 
struction and organization of the world database is the first topic covered in this section. Chapter V. Once the 
data formats and rationale have been presented, we then cover the organization of the software at an abstract 
level, Chapter VI. From there on, the chapters focus in detail on the original software components developed 
as part of this dissertation in more detail. Chapter VII covers how vehicle dynamics are implemented. This 
includes weapons effects and contact detection and response. Population of the VW by computer controlled 
forces is covered in Chapter VIIL The next chapter. Chapter IX, covers the issues of scene management. In- 
cluded in this topic are things like level of detail, culling, and view volume determination. The final chapter 
of this section, Chapter X, covers the network in detail. In this chapter, we discuss the network harness, dead 
reckoning, and bandwidth limitations. 

The final section is comprised of a single chapter, Chapter XI, containing the conclusions, recommen- 
dations, and the contributions of the NPSNET system. The NPSNET User’s Guide and source code is avail- 
able from the author on-line. 
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II. VIRTUAL WORLDS: MAJOR CHALLENGES AND ISSUES 



A. OVERVIEW 

NPSNET represents a significant research undertaking in the development of a workstation based real- 
time vehicle simulation system. It encompasses several of the major areas of computer science, making con- 
tributions to each as they pertain to a real-time vehicle simulation system. In a recent industry survey, prac- 
titioners in the VW field were asked what they viewed as the major challenges of the next decade [MILL92]. 
The twenty-four different answers can be broken down into several major areas: Too Much Hype / Marketing, 
Sociological Implications, Cost Reduction, Machine Limitations, World Complexity, and Human / Computer 
Interaction. The first two items. Too Much Hype / Marketing and Sociological Implications, are best left for 
the MBA’s and the sociologist and will not be discussed further here. The remaining areas are pertinent to 
our work and the application of them are discussed at length in the chapters dealing with NPSNET, Chapter 
IV through Chapter IX. In this chapter, we present some of the major challenges and issues that we had to 
deal with during the development of NPSNET. They are presented briefly in this chapter to lay a foundation 
and to provide an overview of the design decisions that went into NPSNET. These issues are not limited to 
NPSNET, or even workstation based simulation systems, but rather across the entire VW development plat- 
forms. 

B. COST REDUCTION 

NPSNET was developed on the Silicon Graphics Inc. IRIS 4D (SGI) family of workstations. By using 
a commercially available workstation it is possible to amortize the cost of hardware development over many 
users and thereby reducing the unit cost of each of the network nodes. By using a workstation as the hardware 
base, we further reduce the cost of each node since the organization can use the workstation for other purposes 
when it is not involved in a simulation exercise. This is something that the dedicated hardware simulators can 
not do. The use of workstations does complicate the construction of the system since many of the functions 
embedded in hardware in the dedicated simulators must be done in software, thereby slowing the frame rate 
down. A further advantage of using the SGI workstation is that they are software binary compatible across 
the entire workstation product line. This allows the user to tailor the hardware suite to his cost and perfor- 
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mance requirements. The challenge was to use a commercially available general purpose graphics worksta- 
tions instead of special purpose hardware and image generator combination. 

C. WORLD CONSTRUCTION AND MAINTENANCE 

The run-time world database contains two major types of data: the physical characteristics, and the geo- 
metric or visual representation of the icons. Both share the common requirements of having to be flexible, 
expandable, and rapidly accessed. The physical characteristics portion of the database consists of the static 
and dynamic parameters of the entities and responses to stimuli. These are the parameters that are input into 
the rules and functions that govern the behavior of the entities in the VW. The geometric component of the 
world is comprised of the graphics primitives needed to represent the visually correct world. Very often the 
two databases are combined into a single run-time database that makes up the VW. The user then relies on 
the VW software to interact with the database to construct the desired VW. The architecture of the software 
is discussed below. 

The requirements of flexibility and expandablity go together for any computer system. Unfortunately, 
they often are at cross purposes with efficiency. The classic data structures example of this is the linked list 
versus the array. The linked list is extremely flexible and expandable, but requires O(n) access time. The ar- 
ray, on the other hand, is a fixed construct in terms of size and structure, but can be accessed in 0(1) time. In 
the case of NPSNET, speed was more important than flexibility at run-time. As such, we had to develop a 
system that can be configured at start up but still ran efficiently. 

The actual construction of the VW’s physical and geometric databases is not difficult, but is very time 
consuming. The construction of the physical database is task specific and research intensive. Looking up and 
inputting the tremendous number of parameters required to insure correct behavior and appearance takes 
quite a while. In some cases the cost of producing the geometric database exceeds that of the hardware 
[PRC92J. The physical modeling of the icons for the non-run-time geometric database is relatively straight- 
forward and is covered in detail in [SGI92J and [SSI92]. Thus the challenge is to reuse existing databases 
rather than develop new ones. 

D. WORLD POPULATION 

Even with low-cost workstations, there are not enough resources for every simulated vehicle to be con- 
trolled by a human. To alleviate this problem we use scripted vehicles. Semi- Automated Forces (SAF), and 
Autonomous Agents (AA). Scripted vehicle motion is controlled by a prewritten sequence of actions. The 
script can be recorded from a previous exercise, generated by a combat model, or hand written by the scenario 
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designer. A S A F unit has a human exercising control over a key or lead vehicle and all of the other vehicles 
follow the lead. Even though they are following the lead of the key vehicle, they are making small, task level, 
decisions for themselves. An AA is a fully automated unit. In this case, an AA unit would be given a high 
level goal and the automated controller would in turn execute the tasks required to complete the goal. The 
important difference between the two is the removal of the man in the loop. This complicates the construction 
of the agents considerably. The fundamental challenge is to populate with enough entities so that the human 
player can interact with them. 

E. REALISTIC ICON INTERACTION 

One thing that we have noticed in the many demonstrations that we have given is that the user does not 
focus on what is there, but what is missing or done incorrectly. When we first modeled power lines, we did 
it as single line segment from pole to pole. Quite a few people noticed and commented on them. When the 
power lines where modeled as curves, nobody seemed to notice them. The fact that we modeled the lines as 
Bezier curves vice catenary curves, did not take away from the appearance of correctly modeled power lines. 
The reason for this is that one of the fastest ways to destroy the illusion of presence is to present to the user 
something that is incorrect or inconsistent with the user’s expectations. All physical entities behave according 
to certain rules and users expect these rules to be followed. Some of these rules might be physics based, i.e. 
power lines are curved, or doctrinally based, i.e. in the United States you drive on the right side of the road. 
These are the rules that have to govern all players in the VW. The challenge is to make the entities mimic how 
the user expects them to act within the resources available. 

F. MACHINE LIMITATIONS 

Over the last several years, the cost of computer hardware has fallen while the processing power has 
increased by at least an order of magnitude. For example, this year we bought a machine that has two orders 
of magnitude faster graphics and at least one of processing ability for a quarter of the price of a machine we 
bought five years ago. Despite this, NPSNET runs at the same frame rate as FOGM [ZYDA92JSMIT87f 
There is a very simple reason for this. The capabilities of the NPSNET system are enhanced until an unac- 
ceptable frame rate is met. This is the computer graphics version of the closet metaphor, the amount of clothes 
you have will expand to fill all available closet space. This is true not only of the graphics subsystem but also 
of the network and processor components as well. 
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1 . Processor 



The amount of computation that is involved in a networked VW exceeds what is currently avail- 
able from a single Central Processing Unit (CPU). For this reason, we have explored the use of parallel pro- 
cessing and spread the computational load among several processors within a workstation. The use of true 
distributed processing (using the CPUs on multiple machines connected over the network) was considered 
and then discounted. By using the remote procedure call mechanism, we would place an even higher load on 
the network which is the most limited resource we have. This would also add a level of complexity to the 
system we sought to avoid. 

Conceptually, the management routines required by a VW can be divided up into five general pro- 
cesses: User Input Management, Vehicle Dynamics, View Volume Determination, Rendering, and Network 
Management. Figure 1 shows the connection and relationship of each of the processes. The User input man- 
agement routines monitor the state of all the input devices and provides the inputs into the VW. The vehicle 
dynamics process moves the vehicle across the terrain based upon the physical model of the vehicle, under- 
lying terrain, interaction with other entities, and user inputs. In the case of AA or S AF, this process also con- 
tains the intelligence to control the player. Scene Management is the process of placing the eyepoint in the 
world, constructing the field of view (fov), determining what is in the fov or culling, and which polygons will 
be passed to the Tenderer and in what order. Culling is normally a two step process with coarse culling done 
by the culling process and fine grain, or window clipping, done by the Tenderer. The Tenderer process converts 
the geometric primitives into the colored pixels on the screen. The final process is the network management 
process. This process provides network services by monitoring the network, buffering any incoming messag- 
es, and putting any outgoing messages on the network. The challenge is to construct these processes in such 
a way that they all fit within the available CPU resources. 

2. Graphics 

Humans are fundamentally visual creatures; we receive most of our environmental stimuli via our 
eyes. As such, the graphical presentation of the information is critical if we desire to achieve any sense of 
presence. As a result of this, the users are given most of information and feedback by means of a graphical 
representation of an out-the-window (OTW) view. This metaphor is suitable for vehicular simulation, that is 
the way we view the world when we are in a vehicle. The visual realism of the scene and the frame rate are 
the two most important parameters in the display, although there is some dispute which is more important 
{BR0088|. Ideally, the user would be presented with a photographic quality display of the OTW scene at 
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Figure 1. Process Interconnection 

thirty to sixty hertz. Studies have shown that a frame rate of six frames per second (fps) is the minimum frame 

rate for an interactive system [AIRE90A]. Smooth motion starts at fifteen fps and in excess of thirty fps the 
user is unable to visually notice any improvement. Some communities, notably flight simulation, demand six- 
ty hertz update rates due to perceived lag in the system from input action to visual response [E&S91]. Cur- 
rently, no computer image generators (CIGs) or graphics workstation are capable of construction of complex 
photorealistic scenes at any of these rates. For this reason, the requirement exists to develop three dimensional 
icons to represent the items in the real world. The icons are normally reduced polygon representations of the 
real from which the user can draw informational cues. Thus, the challenge is how good of a scene can be pre- 
sented and how fast. 

3. Network 

The NPSNET system was designed from the beginning as a networked simulator. This allows 
multiple users to be on different workstations and interact over the network. The use of the network allows 
players who are not physically co-located to share a virtual space and interact with each other much the same 
way they would if they were in vehicles in the real world. The network is the ideal mechanism to increase the 
scaleablity and adaptability of the system. Thorpe in his paper on SIMNET, [THOR87], calls this ability the 
“dial a war.” What this allows us to do, is to create as simple or as complex an engagement as we want by 
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selecting which and how many simulation systems are going to be connected to the network. In a sense, the 
network is the supreme integration tool. However, it does not come free of cost. In order for multiple users to 
communicate, a standard network protocol and connections must be used. 

The use of a commercially available network imposes certain limitations. The foremost of these 
is the limited bandwidth. This combined with the network latency are the two physical limitations imposed 
by the network. Network management limitations, such as unreliable delivery, also have to be considered. 
Network programming is a complex matter that is poorly understood by most and practiced by few. Yet, in 
order to have a scalable and flexible system, the network must be mastered efficiently. The challenge is to 
develop a simple, yet flexible and efficient, network interface and management routines. 

G. HUMAN COMPUTER INTERACTION 

Since NPSNET was designed to run on a workstation rather than a vehicle mock-up, a new user inter- 
face had to be designed The information had to be presented to the user in such a way that he feels immersed 
in the simulation. In a vehicle mock-up, this is a fairly easy task since the user’s physical setting correspond 
to what he expects to see in the real vehicle. On a workstation, it is a considerably more difficult task. The 
user’s field of view is not completely enclosed by the simulation, but rather only a small fraction of it is oc- 
cupied by the display. The use of large screen televisions increases the amount of viewing area but at loss of 
resolution. Furthermore, since the fov is so small, the user can easily get lost in the VW. To avoid disorien- 
tation, it is co mm on practice to provide a two dimensional Plan View Display (PVD) showing the users lo- 
cation [BROO88]. While this helps the user locate himself, it further takes away from the screen space 
available for OTW view. The OTW view is further restricted when the status information, speed, heading, 
location, etc., are included in the display. Rather than using dedicated input devices, we chose to use a com- 
mercially available joy stick, mouse, keyboard, and button and dial box as input devices. This further helped 
to reduce the sense of immersion. 

To see what can be done with simple interfaces like the one we are using, we went to the local video 
arcade. It does not take long to notice the games that the customers are playing have three major features in 
common, fast graphics display, sound and high degree of interactivity. These three features, when combined 
coherently, possess that ability to completely immerse the user in the VW. The challenge then became to com- 
bine these areas on the workstation to immerse the user in the VW. 
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H. CONCLUSIONS 



As stated above, a lot of work has been done on these challenges, not just at NPS but at other places as 
well. Some of these systems are presented in the next chapter. The key thing to remember is that there are 
significant technological limitations to the underlying hardware. It is the design and construction of the en- 
abling software that can compensate for these limitations. That is the primary purpose of NPSNET, to serve 
as a software architectural frame work for the construction and management of real-time virtual worlds. 
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III. OVERVIEW OF SIGNIFICANT EXISTING VIRTUAL WORLD SYSTEMS 



A. OVERVIEW 

While NPSNET is not the first VW system, it is one of the most ambitious and useful ever undertaken 
by an academic institution. Like all research, it is built on the systems that have gone before it In this chapter, 
we review some of the more well known systems. While these systems were chosen as a representative sam- 
ple of a certain types of VW applications and implementations; it is by no means an all inclusive list Other 
VW systems are referenced in the rest of this document where they are applicable. 

B. VIDEOPLACE 

Krueger developed the first in the series of video based systems in 1970 when he was at the University 
of Minnesota. Videoplace is unique among the systems discussed here in that it is video based [KRUG91J. 
The user is placed in front of a lit white Plexiglass panel, to provide a high contrast for the video cameras. 
The cameras are then aimed at the user to record images. These images are then processed with custom hard- 
ware and combined with computer generated images. The resulting images are then displayed on a large pro- 
jection screen. The use of video technologies allows thirty hertz input / output rates. These rates, combined 
with the custom hardware, provide for an extremely interactive system. The basic premise of Videoplace is 
that the human silhouette can interact with itself, other silhouettes, or computer generated entities. This par- 
adigm allows for a wide range of possibilities. In his book, [KRUG91], Krueger discusses some of these po- 
tential applications at length. The common thread through all of them in that they are art or interpersonal 
communications systems, rather than scientific or exploratory systems. 

The very strength of the system is its limiting factor. Since all motion tracking and input is done via 
video cameras, the system is inherently two dimensional. While it is possible to construct a three dimensional 
version by using orthogonal cameras, the display is still a projected image on a screen. Likewise, since the 
system uses a back lit panel, the size of the world is limited to the size of the panel. Based upon observations 
of a version of Videoplace at the Tomorrow’s Realities Gallery at SIGGRAPH 1991 , the users quickly tire of 
the paradigm, despite the high level of interaction. 
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C. REALITY BUILT FOR TWO 



Reality Built for Two (RB2) is a combination of off-the-shelf hardware and VPL’s custom software 
[BLAN90][BLAN92]. The key aspect of this system is the complete immersion of the user. This is done by 
the use of VPL’s EyePhones and DataGlove. The EyePhones, VPL’s trademarked name for their helmet 
mounted display (HMD), completely blocks the user’s field of view. As a result, the only visible image are 
the computer generated graphics presented on the two small LCD displays. The computer graphics displayed 
in the HMD is a subset of the VW that was modeled using RB2 Swivel. Once the user is satisfied with the 
world created by RB2 Swivel, it is then exported to the SGI IRISes for traversal and rendering. The Data- 
Glove, a full hand input device, is used to interact with the system. Both the DataGlove and the EyePhones 
have Polhemus sensors mounted on them to sense the position and orientation of the user’s hand and head, 
respectively. The input data is fed into a Macintosh II and is processed by the Body Electric Software that 
computes the world dynamics and the viewpoint. The dynamics of the system can be modified by the visual 
programming interface provided with Body Electric. When the dynamics of the frame have been computed, 
the frame generation synchronize signal to the two SGI Irises is set and Isaac, the real-time renderer, renders 
the scene for each of the eyes. Recently, the Crystal Rivers Convolvotroo was added to the system to provide 
3D sound cues to the user and thus increase the feeling of presence in the VW. The use of two graphics en- 
gines to drive a single HMD is not unique. Since many of the graphics engines do not handle two simulta- 
neous visual channels very well. This fact alone has increased the cost of an HMD based system by almost a 
third. 



D. THE VIRTUAL WIND-TUNNEL 

The Virtual Wind-Tunnel is a system designed and built at the NAS A- Ames Research Center to explore 
numerically generated unsteady flow fields [LEVI92]. In this system, the flow fields around an object are 
computed a priori and stored for use by the simulation system. A DataGlove is used to place the start of the 
marker flows. These flows are represented as a stream of “bubbles” going across the display. The location of 
each of the “bubbles” is determined by the previous location and the direction of the flow. The in-between 
positions are computed by means of a second order Runga-Kutta integration to give a smooth flow across the 
screen. By moving and gesturing with the DataGlove, the starting location and number of marker flows can 
be modified. This allows the user to keep the number of flows to a minimum, while still being able to examine 
the areas of interest. The flows are presented to the user by means of a pair of boom mounted CRTs. CRTs 
can be used for this application since all the weight is supported by the boom and not the user’s head. The 
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CRTs are also brighter and have better resolution than the LCD displays. However, they are monochrome. 
Through clever manipulation of the red and blue bit planes, the designers are able to generate stereoscopic 
displays from a single channel display. While the boom mount does not have the same freedom of motion as 
an HMD, it is adequate for the representation of the data. The key feature of this system is its ability to com- 
bine a static database, the flow field data, and the dynamic actions of the particles and present the results to 
the user in an intuitive manner. 

E. BOLIO 

The Bolio system is the name given to the Integrated Graphical Simulation Platform (IGSP) designed 
and built by Zeltzer’s group at the MIT Media Lab [BRET87][ZELT89A][ZELT89B]. The interesting point 
of this system is the use of reusable modular components that can be linked at compile time to form a tailored 
system. This has allowed the system be used for such diverse research projects as insect locomotion, teleop- 
eration of robotic arms, user interaction, and path planning [STUR89A][STUR89B]. 

Bolio is built around the traditional input / compute / draw loop. It is this loop that provides that flexi- 
bility in the system. The input modules can be drivers for such devices as the keyboard or a DataGlove. The 
key aspect is that they all provide a standard interface. The same is true of the compute or dynamics section 
of the loop. If the user wants to include complex dynamics or control routines, the rest of the code does not 
have to be modified as long as the routines conform to the standard interfaces. The graphics routines are 
slightly more specific due to the nature of the graphics calls and platforms. It is this flexibility and reuse of 
code that has allowed one single set of software to be used for a diverse set of applications [ZELT89A]. An 
excellent overview on how Bolio can be used as a harness for task level animation can be found in f BADL91 ]. 

The flexibility does not come free of cost. Bolio is capable of supporting only eight simple polyhedral 
objects at five frames per second [DWOR9 1 ]. Part of this is due to the platform and part is due to the software 
harness overhead required to support the generic interfaces. 

F. UNC WALK-THROUGH / MOLECULAR MODELING 

The Department of Computer Science, University of North Carolina at Chapel Hill (UNC) has con- 
structed many separate virtual world systems (RHEI91 ). For the sake of this overview, we focus on two of 
the main thrusts, architectural walk-throughs and molecular modeling. 

The initial UNC work on architectural walk-throughs was driven by their desire to visualize the new 
computer science building before it was built The initial version of the work, first presented in [BROO 86 ], 
was an 8000 polygon model of the building and used a Binary Space Partitioning (BSP) tree for hidden sur- 
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face removal. The output was displayed on a wide screen projection system, standard monitor, and a stereo- 
scopic display. The input of the building data in the system was done by a combination of Autocad and a 
modification to a microchip design program. The data was then preprocessed into the working model before 
it was passed to the View instancer for viewpoint selection and rendering. The view point was selected by 
means of a mouse, Polhemus, data-tablet, or joystick. The resulting system provided a frame about every 
three seconds. The third version running on one of the early versions of UNO’s Pixel-Planes image generator 
was able to achieve nine frames per second. To partially compensate for the frame rate, a two dimensional 
floor plan was also provided to help the user navigate through the building.[BR0086] 

The work cm walk-throughs was extended in [AIRE90A] and [ AIRE90B]. There were two fundamental 
improvements on the original system: better database organization and improved lighting model. The data- 
base was reorganized into Potentially Visible Sets (PVS) rather than a pure BSP tree. This takes advantage 
of the properties of buildings. Buildings are divided into a series of rooms, therefore, not all polygons in one 
room are visible from all other rooms. Likewise, after the design process is complete, buildings form a rela- 
tively static database. The PVS organization allows for the rapid culling of the non-visible polygons in the 
other rooms. This is similar to the work done by Funkhouser for the new computer science building at the 
University of California, Berkeley [FUNK92]. The second improvement was the addition of a radiosity light 
model. The use of radiosity and its use of diffuse lighting characteristics and polygon subdivision improves 
the overall image quality. When the user is moving, the coarse flat shaded model is used. When the viewpoint 
is stationary, the coarse polygon model is replaced by progressively more complex radiosity lit scenes. 

The area of molecular modeling has been an active area of research at UNC [BR0077][BR0088]|0U- 
HY89][BROO90][SERL92]. Specifically the areas of force feedback, dynamics, and Helmet Mounted Dis- 
plays (HMD) have been stressed. The work on force feedback has made extensive use of the Argonne Remote 
Manipulator (ARM) device. This is a robotic remote manipulator arm commonly used for the handling of tox- 
ic and radioactive materials in an isolation booth. This proved to be particularly useful for the GROPE and 
GRIP series of projects since the servo motors controlling the movement of the arm could be controlled to 
provide resistance, both positive and negative, to the user. The construction of the ARM allows the chemist 
to try to physically fit the molecules together and feel the forces involved. Audio cues provide an additional 
channel to the user’s senses for conveying information. The use of HMDs has given the chemist the ability 
to view molecules in three dimensions and study the forces and the orientations of the individual atoms. The 
key contribution of this work has been that of visualization and manipulation of a physical phenomena in a 
intuitive and computationally correct manner. 
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G. SIMNET 



To a large extent, DARPA’s and the US Army’s Simulation Networking (SIMNET) system can be con- 
sidered the only true virtual world system in existence today [THOR87][GARV88][IDA90]. When SIMNET 
was initiated in 1983, it was meant to serve as a proof of principle technology demonstration of a networked 
man in the loop, real-time, immersive battle simulation [IDA90f It has since grown to over fifteen sites ca- 
pable of conducting a mechanized battalion level engagement with close air support [GARV88]. 

The history of SIMNET is a classic example of a DARPA high risk research project that has had a fun- 
damental impact on how training is conducted. The idea for the use of computer graphics grew out of the use 
of the video disk based gunnery trainers of the late seventies and early eighties. These trainers could train an 
individual tank crew, but could not teach the interaction between the tanks. For this, a radically new approach 
had to be taken. The tanks had to interact with both the targets and each other. Clearly a network connection 
was required. To construct a system such as this required a quantum leap in the technology of the day 
[IDA90J. 

DARPA assumed the project management role and the subcontractors, BBN, Deltagraphics, and Per- 
ceptionics built the dedicated and task specific hardware and software required for the simulators. DARPA 
realized at the time that task specific hardware was not the best solution, but since no commercially available 
systems met the specifications, it was the only way to go. The resulting hardware configuration is shown in 
Figure 2, all of which is available from a single vendor, BBN.[IDA90j 

As Thorpe points out in [THOR87], the key to the success of SIMNET is the network connecting the 
microprocessor based simulator nodes. Figure 2 shows the architecture of the SIMNET node. Normally, mul- 
tiple nodes are connected via the Ethernet network to provide force-on-force engagements. Figure 3. The use 
of the network allows a certain amount of scalability and flexibility that is not normally found in the more 
traditional combat models. The ability to “dial -a -war” allows the network to be used for multiple engage- 
ments at the same time and for a task organization of the equipment mix. 

The use of a standardized network protocol allows the connection of dissimilar equipment to the net- 
work [POPE89]. It is these protocols that communicate the changes of each entity’s appearance, and the tran- 
sient events it generates, to the rest of the s imula tors on the network. The majority of the network traffic is 
the Appearance Protocol Data Unit (PDU). This PDU contains the information required for first order dead 
reckoning 1 , location, orientation, and speed. As long as an entity’s speed and orientation does not change, 

1 . Dead Reckoning is discussed in detail in Chapter X. 
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there is no need to send an appearance PDU across the network. This significantly reduces the network load- 
ing and allows more entities to be modeled. By their very nature, transient events, such as weapons fire, det- 
onations, collisions, and resupply, are not predictable events. As a result, whenever this type of event occurs 
a PDU is sent out. 

SIMNET was and is a success because a tremendous amount of time and effort were spent on the func- 
tional requirements of mechanized combat Even with this limited scope, SIMNET never was intended to be 
the complete or perfect solution. But rather it introduced the concept of a 70% solution. If the most important 
cues are provided to the user, the user’s mind is able to fill in the remaining details. By putting the user in an 
enclosed environment, the tank or aircraft mock-up, and providing him with auditory and visual cues, even 
cartoon like graphics, the user quickly becomes immersed in the interaction with the other players on the net- 
work. [THOR87IIDA90] 

SIMNET’s success at team tactics training has been mirrored with its role as a test bed for new weapons 
system development This was demonstrated in the Line-of-Sight Forward Heavy (LOS-F-H) test conducted 
in 1988. This test was designed to determine the effectiveness of a weapon that was still on the drawing board. 
The weapons systems were modeled in software and connected to the network. This test proved two important 
things. The first of which is that weapon’s effectiveness and tactics can be evaluated prior to it full scale con- 
struction and deployment. Once the tactics were developed, they could be practiced and further refined. This 
would have normally occurred at costly, controlled, and scarce field trials. In many cases, the tactics would 
have to be discarded in actual combat The other was the use of a detailed recording capability for the after 
action review. By examining the events that happened, the users were able to determine exactly what was 
going on and how to counter advances by the other side and exploit their equipment. [GARV88) 

The SIMNET System, or Planet SIMNET as it is sometimes called, is a true virtual world system since 
it covers a large geographic area, has many players, the players interact in an intuitive manner, the users action 
are reflected in the world state, and the users feel immersed in the action. In many ways, this is the holy grail 
of virtual world systems. It’s weaknesses are the very things that made it a success. A task specific suite of 
hardware and software are available from only one vendor. The rapid development lead to poorly documented 
and ill structured code. While it has proven to have limited flexibility and scalability, it suffers from growing 
pains and technological limitations of the hardware. 
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H. SUMMARY 



In this chapter, we have seen some of the major VW systems and their uses. It is from some of the ideas 
gathered from the study of these systems, and other work done at NPS, that NPSNET was built. Ideally, what 
we would like to have is a system with the complexity of SIMNET, the real world modeling ability of the 
Virtual Wind Tunnel, the flexibility of Bolio, the sense of presence of RB2, the interaction of Videoplace, 
and the durability and usefulness of UNC’s work. Our system may not yet achieved all of these goals, but, as 
shown in the next chapter, it comes pretty close. 
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IV. NPSNET OVERVIEW 



N PS NET was designed and built at the Department of Computer Science, Naval Postgraduate School, 
as a test-bed for the exploration and experimentation of virtual worlds. As part of the design process we care- 
fully reviewed all of our previous simulators; FOG-M, VEH, MPS I, MPS II, MPS III, and CCWF [SMI- 
T87][OLIV881[FICT88][WINN89|[CHEE90][WEEK89]. Each one of these had some interesting 
components, but they also had some weaknesses. What we did in NPSNET was to extract the useful algo- 
rithms and develop new ones as needed to implement the desired features. In this section, we discuss in detail 
the database formats, structure of the software, and the algorithms needed to populate the world, manage the 
network, move the entities, and efficiently manage the graphics pipeline. 

NPSNET started in February of 1990 as a test bed to explore a proposed terrain database format Since 
that time, over ten master’s level students have contributed to its development. What started as a simple single 
vehicle with one kilometer square world, now has expanded to a fully networked system capable of support- 
ing 500 vehicles of any of 2000 different types in a world exceeding 100 kilometers on a side. As NPSNET 
has continued to grow, it has been compared favorably to the U.S. Army’ s SIMNET system. While this is 
true in many respects, there are some fundamental differences. The foremost among these is the equipment 
that the system was designed to run on. NPSNET can run on a single SGI Indigo Elan, while SIMNET re- 
quires a vehicle mock-up, computer image generator, host computer, and sound generator. The SIMNET sys- 
tem is also extremely weapon system specific. The node configured to emulate an M 1 cannot be reconfigured 
to become an M2. The lost of flexibility comes from the use of the mock-up and the complexity of the simu- 
lator code. The mock-up adds a sense presence and realism that NPSNET, a workstation based system, does 
not match. NPSNET was designed to be as flexible and extensible as possible. To a large extent, this prevent- 
ed the inclusion of some of the more specific weapons systems features. However, since the system is exten- 
sible, we have been able to add some of these features into certain versions of NPSNET. 

Rather than 

using an accurate vehicle mock-up, NPSNET users interact with the system by means of a Spaceball, 
Keyboard, Buttons / Dials box, and/or Mouse. Having a wide variety of controls allows the user to select the 
interface metaphor that is most appropriate for the task and what the user feels most comfortable with using. 
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Recently, the Ascension Bird and VPL Eye Phones have been added to the available input and output devices. 
Figure 4 contains a diagram showing the NPSNET controls. 

NPSNET was designed to run on a single workstation. As such, the available visual display was limited 
to that of a single display console. The current display. Figure 5, is a combination of the 3D out-the-window 
(OTW) view, the 2D elevation shaded map, and the information panel. The size and the location of the 3D 
OTW view was determined by default, that is the screen area that is covered by the scan converter we use to 
record the graphics display. Across the top of the screen is the information panel. This window contains tex- 
tual information such as location, speed, orientation, frame rate, and weapon status. The third window is the 
optional 2D elevation shaded display. The 2D map can be hidden if the user decides that the screen space is 
better utilized by the 3D OTW view. The advantage of this window is it shows the vehicle’s location in the 
world with relation to all the other vehicles and the database. 




Figure 5. Annotated NPSNET Screen 

Since the initial release of NPSNET in the Fall of 1991, over forty schools, government organizations, 
defense contractors, and commercial firms have received at least one version of NPSNET or some of the sup- 
port code. The uses for this code include: autonomous agent studies, constructive combat model visualization, 
terrain visualization, weapons evaluation, and low cost stealth nodes. It is the flexibility and modularity of 
the code and of the database that allows a single system to be readily adaptable for these varied uses. 
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Figure 4. NPSNET Controls 
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V. VIRTUAL WORLD DATABASE CONSTRUCTION 



The NPSNET world consists of three interconnected components. The first of these is the terrain skin. 
This is implemented as a polygonal covering to represent the topology of the area. Different colors and tex- 
tures are used for the polygons to convey a sense of soil or ground cover type. Fixed zero height features, such 
as roads, rivers, lakes, and fields, are all part of the polygon skin. Anything that is static on the database but 
has an elevation, such as buildings, trees, and telephone poles, are part of the second database. These static 
objects are used to increase the complexity and thus the realism of the world database. The final database is 
the dynamic entity database. This database contains all of the players that move in the world. The first two 
databases are discussed in this section, the dynamic entity database is covered in Chapter VII ENTITY DY- 
NAMICS. The icon database that contains the description of the static and dynamic entities is part of the static 
entity database. 

The world in NPSNET is that of ground combat. As such there are certain features we can exploit. 
While the world is three dimensional, all of the objects are attached to the ground. All of the action occurs on 
the ground, or in relatively close proximity, and no entity goes below ground level. As such, the terrain is only 
a single polygon deep. Thus, the world segmentation ends up being a 2 1/2 D problem, 3D environment pro- 
jected on to a 2D plane. When we model such things as buildings, a 3D representation is used to segment the 
world. Another feature we can exploit is that the players are relatively slow moving objects. Obviously, mis- 
siles and ballistic projectiles are the exception. As shown in Table 1 , even ballistic weapons do not travel a 
significant distance, often less than one unit of database resolution, during one frame. Since this is the case, 
we can reduce the computational and graphics load by limiting the search area and grouping the objects to- 
gether. 

Ground combat engagements take place over a limited area. Wars might cover thousands, or even mil- 
lions, of square kilometers, but battles seldom cover more than a couple of hundred square kilometers. This 
allows the use of a Casini flat earth projection 1 for the terrain database and the use of Universal Transverse 

1. A Casini projection is an equidistant flat earth projection. It is only valid for small areas of the 
earth since it discounts the curvature of the earth and the differing distance separating longitude 
lines at different latitudes. In essence, one degree of longitude is held as a constant for the entire 
database resulting in the flat earth model. For large differences in latitudes, the approximation error 
results in extremely inaccurate placement and navigation. 
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Mercator (UTM) coordinates. The assumption that the players are concerned only with local areas is signifi- 
cant in that it allows the segmentation of the world into different regions. This also limits the viewing distance 
requirements. The player does not have to see beyond the range of its sensor and weapon systems. 2 



Table 1 : DISTANCE TRAVELED PER FRAME 



Player Type 


Speed 

(KPH) 


Speed 

(Meters/Sec) 


Frame Rate 


Max Distance Per 
Frame (Meters) 


Ground 


100 


27.76 


15 


1.85 


Ship 


50 


13.88 


15 


0.93 


Aircraft 


1400 


388.89 


15 


25.93 


Ballistic Munition 


3000 


833.33 


15 


55.56 



A. COORDINATE SYSTEMS 

NPSNET uses two right handed coordinate systems, one for the world and the second for the icons’s 3 
body coordinates. As shown in Figure 6, the world coordinate system has (0,0,0) located at Mean Sea Level 
(MSL) at the upper left hand, or northwest, comer of the database. The positive X axis is heading east, posi- 
tive Y is the altitude above sea level, and Z increases to the south. This is contrary to almost all other simu- 
lation and Geographic Information Systems (GIS). But on the Silicon Graphics architecture it is more 
efficient The orientation of the world coordinate frame allows us to keep the database in the positive XZ 
quadrant and the vehicle’s heading is the simple offset by ninety degrees from the normal zero degree heading 
being north. When information is presented to the user, all values are given as if the origin was in the south 
west comer with X being east, Y north, and Z being elevation. 

The body coordinate system was likewise chosen for efficiency, Figure 7. The X axis is to the front and 
roll causes the right side of the vehicle to dip down. The Y axis represents the height of the vehicle, yaw turns 
the icon to the left. Heading, which is about the Y axis in world coordinates, is positive rotation to the icon’s 



2. Much of the implementation work in this section was done with two of my thesis students, Wil- 
liam Osborne and Randall Mackey. The ideas and algorithms were developed during many long 
conversations and tutorials. They did the preliminary implementations, 1 have redone significant 
portions of their code and algorithms after they completed their degrees. Portions of this work has 
appeared in their master’s level thesis, [0SB091] and [MACK91]. 

3. For the purpose of this dissertation, we will use Zyda’s definition of a 3D icon as a low polygon 
count representation of a real world object [ZYDA90A]. The purpose of the icon is to give the user 
the visual cues required to identify the presence and type of an object, not necessarily a faithful rep- 
resentation of the object’s true appearance. An object is a specific instantiation of an icon at a par- 
ticular location and orientation. 
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Figure 6. NPSNET World Coordinate System 



right. With the exception of some work done on aircraft dynamics, we use heading exclusively. The Z axis 
extends out the right side of the vehicle. Rotation about the Z axis, pitch, results in the nose of the icon rotating 
up. Unfortunately, this set of coordinate axes is also nonstandard. To compensate for this, most models from 
other sources have to be rotated about X and Z to be in the proper orientation. The origin of all the icons is 
positioned in such a way so that when they are sitting on the ground their origin is at ground level. This sim- 
plifies the placement of the objects greatly by not requiring the projection of the models onto the terrain. 

In order to maintain constancy with most military systems, all distances are measured in meters. One 
unit of UTM equals one meter. Internally, all angular measurements obey the right hand rule. However, when 
information is presented to the user, or external interfaces, the intuitive and / or standard units of measurement 
and reference points are used. 

B. WORLD SEGMENTATION 

In order to construct an efficient VW world database, a firm understanding of the limitations and capa- 
bilities of the hardware is required. As shown in Table 2, the number of polygons passed to the graphics pipe- 
line has a major impact on the frame rate performance of the system. Other factors, such as the texturing of 
the polygons, depth complexity, and vertex transformation all have an impact on the system performance as 
well. In this section, we discuss how the world can be segmented to minimize the number of polygons passed 
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Figure 7. NPSNET Body Coordinate System 

to the rendering process. Not only does the segmentation of the world benefit the rendering process, but as 
shown in Chapter VII ENTITY DYNAMICS and Chapter IX SCENE MANAGEMENT, it helps to speed up 
and simplify other aspects of the VW as well. Table 3 shows the distribution of objects based verses the size 
of the grid squares used to segment the world. This data was derived from the Fort Hunter Liggett terrain da- 
tabase [LAJNJG90]. This database is a representative sample of a populated 3D VW database and is commonly 
used due to its lack of security classification. The database is of average size, fifty kilometers square. The 
distribution of the objects is slightly skewed in that the database contains a portion of the ocean along the 
southwest comer and a significant number of canopies. The canopies are used to represent a densely wooded 
area, thereby reducing the polygon count. The average object count among populated grid squares, ones that 
contain at least one object, is 3.9. The icons used to represent the objects average seventeen polygons each. 
The last column in Table 3 assumes constant terrain polygon skin density of two polygons for every 125 meter 
square area. From the tables, we can see that if we passed the entire database to the rendering pipeline, we 
would get a new frame approximately every three seconds on a SGI Iris 240/VGX. To achieve our desired 
goal of thirty fps, at most two 1000 meter grid squares can be used. Of these two grid squares, approximately 
one full grid square will be clipped out by the window clipping. The smaller the grid squares, the less of them 
will be clipped out by the window clipping and more can be put in the field of view. This allows us to optimize 
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the number of polygons passed to the graphics pipeline. A more detailed discussion of scene management can 
be found in Chapter IX SCENE MANAGEMENT. 



Table 2: POLYGONS IN SCENE VERSUS FRAME RATE 



Polygons In The 
Scene 


Rendering Speed 8 
(Polygons per 
Second) 


Time To Render 
One Frame 
(Seconds) 


Frame Rate b 


1,000,000 


30,000 


3.3333 


0.3 


10,000 


30,000 


0.3333 


3.0 


1,000 


30,000 


0.0333 


30.0 


500 


30,000 


0.0167 


60.0 


100 


30,000 


0.0033 


300.0 



a. The figure of 30,000 polygons per second is considerably lower than most manufactur- 
ers claim for their image generators. Since most of the performance specifications come 
from optimized tests, the claimed number can be very misleading. 30,000 is an approxi- 
mate number of effective polygons per second that can be achieved in a VW application. 
[ORT091] 

b. The Frame Rates can be misleading at the higher numbers. Many graphics display 
devices have a minimum refresh rate, pixel fill rate, vertex transform rate, and maximum 
buffer swapping rate which prevents the frame rate from going above a certain rate, typi- 
cally around sixty hertz. Also, other factors such as a minimum application delay time 
limit the number of frames possible in any given time span.[HUSN91] 



Table 3: DISTRIBUTION OF OBJECTS IN THE FORT HUNTER-UGGETT TERRAIN DATABASE 



Grid Square Size 
(Meters) 


Maximum 
Number of 
Objects per Grid 
Square 


Number of 
Grid Squares 


Average Number 
of objects per 
Grid Square 


Average Polygon 
Count per Grid 
Square 


125 


18 


160,000 


0.20 


5.38 


250 


36 


40,000 


0.79 


45.51 


500 


164 


10,000 


3.18 


182.10 


1000 


329 


2,500 


12.71 


728.90 


50,000 


31,779 


1 


31,779.00 


860,243.00 



To segment the world, there are three basic approaches. The first two, quadtree and gridded, are location 
based. A location based subdivision has the database segmented by the location of the object in the VW. As 
a result, a tree and a building could be in the same segment if they are close enough to each other. The two 
methods differ in the their hierarchical structure. As shown in Figure 8, the quadtree is based on the recursive 
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spatial subdivision of the area. Each one of the quadrants is subdivided into four sub-quadrants until some 
minimum resolution is reached. For a much more in-depth discussion of quadtrees and their applications, re- 
fer to [SAME90al and [S AME90b]. The gridded subdivision. Figure 9, has a flat single level structure based 
upon a single fixed resolution. The remaining database segmentation scheme is to break the VW up by object 
type. Figure 10. In this scheme, all the trees of the same type are grouped together regardless of their location 
in the VW. The location based subdivision methods are efficient in terms of location queries, i.e. what objects 
are close to Point X and Point Y, but inefficient in the determination of type based queries, i.e. where are all 
the large oak trees. The object type segmentation scheme is the reverse. Since almost all of our database que- 
ries are location based, i.e. render all objects in this grid square or what is the pitch and roll at Point X, we 
chose a location based approach. 




One version of NPSNET 4 uses a combination of the two location database segmentation methods. As 
shown in Figure 1 1, the resulting structure is a grid of quadtrees. Each of the quadtrees covers one square 
kilometer and is rooted at the northwest comer indexed by the location in kilometers. The quadtree contains 



4. During the three years of development, several different version of NPSNET were built. For the 
most part we are discussing the developmental version of NPSNET, not the Demonstration or 
Stealth version. When those systems are discussed, it is explicitly noted. 
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Figure 9. Gridded Terrain Database Subdivision 
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Figure 1 1. Terrain Database as an Quadtree Grid 



four levels of resolution. The 125m is the source data and the lowest resolution. The 250m, 500m, and 1000m 
resolution polygons are generated by down sampling the Digital Elevation Matrix (DEM) for the elevation 
vertices. 

The distance between two of the elevation posts is called the post spacing, Figure 12. The elevation 
posts are the measured and correlated points of reference to the real world. The post spacing is also known as 
the resolution of the database, while the correlation of the elevation posts to their real world location is the 
accuracy of the database. It is possible to have a database with a one meter post spacing, and an accuracy of 
four to five meters. Ideally, the accuracy and the post spacing should be as small as possible. However, as 
shown in Table 2, the more polygons in the scene, the slower the frame rate. This forces a compromise be- 
tween frame rate and terrain resolution. This is discussed in more detail in Chapter IX SCENE MANAGE- 
MENT. Figure 12 also shows the overlaying of the second and third level quadtrees on the underlying gridded 
terrain. 



C. TERRAIN SKIN GENERATION 

NPSNET uses two types of terrain, mesh and polygonal. Depending on the source data, one or both ver- 
sions of the terrain are constructed. If all that is available is a DEM, we only construct the mesh version since 
no information is lost. If the source database contains vegetation, road, river, and soil type information, also 
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known as 2D culture files, both representations are constructed. The mesh representation is created first and 
then, if needed, the polygon representation is constructed over the array of elevations from the mesh. 



NPSNET uses a constant grid post spacing in both the X and Z directions in terms of meters. One of the 
most common sources of terrain data is the Defense Mapping Agency’s Digital Terrain Elevation Data 
(DTED) [DMA86]. DTED is available in one degree by one degree cells, nominally sixty nautical miles 
square. Level 1, three arc seconds data, has a nominal resolution of approximately 100 meters between posts. 
Level 2, one arc second, has data approximately every thirty meters. The data is stored in terms of the spher- 
ical coordinates that have to be converted to the Cassini projection. In the Cassini projection, the constant 
spacing in the spherical coordinates results in unevenly spaced elevation points. To convert the data into a 
constant spaced grid, a location weighting scheme is used. Figure 13. The NPSNET grid post is the weighted 
average of all the DTED grid posts within one grid size radius of the desired point. This results in the intro- 
duction of some error in the elevation of the grid posts. The error introduced is small compared to digitization 
error of the source DTED data. The specification states that the DTED elevation posts will correlate to the 
corresponding real world locations within thirty meters in the X, Y, and Z directions. If a constant spaced 
DEM is used as input, the interpolation routines are not needed and the accuracy of the database is preserved.- 
Mesh terrain, the simpler, faster, and less realistic of the two, uses the SGI GL t-mesh routine for rendering. 
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Where X = One post spacing weighting factor 

SD = Dist IB + Dist 1C + Dist ID + Dist IE 



Figure 13. Construction of Elevation Grid from Unevenly Spaced Points 



Figure 14. The vertices are the grid posts. The elevations are stored at each of the grid posts, while the X and 
Z coordinates are computed from the post indices and the post spacing. The advantage of this method is the 
fast rendering of the terrain skin. Each grid post is passed to the rendering pipeline twice, once for each strip, 
rather than six times, once for each adjacent triangle. Depending on the number of grid squares in view, this 
results in a speed up of one to two frames per second on a SGI 240/VGX. The down side of this approach is 
the loss of the roads and micro-terrain that can be represented in the polygonal version. Each strip is drawn 
from start to finish with no breaks for the decaling of the road polygons. Since the finest resolution terrain 
polygon is the upper or lower triangle, it cannot accurately represent the underlying true shape of the soil 
types and vegetation. 

The polygonal terrain gives a much better representation of the surface features of the terrain and allows 
for the efficient placement of roads. Triangles are used as the default shape for the polygonal skin since they 
are guaranteed to be planar. The polygonal representation of the terrain allows for multiple polygons within 
the bounds of the upper and lower triangles. Figure 15 shows how a lake and the surrounding shoreline are 
decomposed into the component polygons. After subdivision, the polygons are grouped by grid square into 
upper and lower triangles. This ensures that all the coplanar polygons are together. The guarantee of planarity 
allows the user of the Z-buffer decaling algorithm to decal the roads over the terrain skin [AKEL90]. The 
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Figure 14. Construction of T-Mesh Terrain 

generation of the roads and the priority scheme are discussed in detail in the following section, “ROAD / RIV- 
ER OVERLAY”. In addition to the speed penalty for using polygons versus t-meshes, the other drawback is 
the introduction of T vertices. These are places where three polygons abut each other. Due to numerical pre- 
cision errors in the hardware, a pixel might drop out and the background color bleed though. In these cases, 
this is especially noticeable when screen subdivision is used to improve the appearance of the textures. The 
work around we used was to draw a big polygon under the terrain that was the same, at least very close to the, 
color of the terrain. This way the bleed through was not as noticeable. However this does require the rendering 
of an additional large polygon and increases the scene depth complexity. 

D. ROAD / RIVER OVERLAY 

The road and river datafiles are most often provided as a network of vertices and segments. The seg- 
ments then have to be expanded to the width specified by a width attribute. This process, depicted in Figure 
16, can be broken down to three major steps. The segment, defined by Point 1 and Point 2 in Figure 16 A., is 
expanded into the polygon shown in Figure 16B. This can be done in the general case by determining the di- 
rection of the segment, then by constructing two points one half the road width plus and minus ninety degrees 
from the end point. In Figure 16B, Point 1 generates Point A from one half the road width and plus ninety 
degrees, Point B is offset negative ninety degrees. The same process is repeated to generate points C and D. 
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The resulting road polygon is defined by points A, B, D, and C. This polygon is then projected on the DEM, 
Figure 1 6C. The next step is to decompose the road polygon into polygons that are planar with the upper and 
lower triangles generated by the DEM. The resulting vertices are generated one of three ways: Original road 
polygon vertex, DEM elevation post, or Intersection of the side of the DEM polygon and the side of the road 
polygon. Once the vertices are generated, they are sorted in counter clockwise order. The ordering of the ver- 
tices is simplified by the fact that the intersection of two non-concave polygons is guaranteed to be non-con- 
cave. Thus, we can simply average the points to find an interior point and determine the angle to each of the 
vertices from the center point. Sometimes, a single vertex is generated multiple times. The most co mm on rea- 
son is a DEM elevation post and points generated by the side intersection process being the same point. To 
remove the duplicates, all points are checked to see how close they are to the next point in the sorted list If 
two or more points are within a certain tolerance, normally 0. 1 meters, they are considered as duplicates and 
all but one of them are discarded. As shown in Figure 16D, it is not uncommon for a single road polygon to 
generate upwards of ten polygons. 

The generation of the texture coordinates is shown in Figure 17. The texture map is assumed to cover 
the width of the road once. The texture pattern repeats over the length of the road polygon once every road 
width. To determine the S coordinate of the texture, a line is constructed from the end segments through the 
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Figure 16. Construction of a Road Polygons 

point in question. This line is parallel to the original segment and perpendicular to the end segments. The dis- 
tance from the intersection of the start end segment to the point in question along the new line is divided by 
the road width. The resulting value is the S coordinate. A similar approach is taken to determine the T coor- 
dinate. This line is perpendicular to the original segment and parallel to the end segments. The distance from 
the right hand road polygon edge, Side BD in Figure 16, to the point in question divided by the road width 
gives yields the T coordinate. 

As mentioned above, the roads are decaled onto the terrain using the algorithm in [ AKEL90]. To do this 
efficiently, we had to develop a polygon priority scheme. The scheme, shown in Figure 18, contains the rel- 
ative priority of each polygon of the polygons in the grid square. The lowest number is the first one drawn, 
the highest last. The polygonal skin has a priority value of one, indicating that nothing is below it. Priority 
values between two and ten are decaled onto the terrain. Currently ten, the road level, is the only one used in 
this range. As the polygons are read into the preprocessor to create the quadtrees, they are sorted in ascending 
order. This way the rendering process can quickly check for any road segment that has to be decaled. Like- 
wise, this guarantees that any canopies and objects will be drawn last. The object priority value, ninety-nine, 
is a special flag indicating that it is an instantiation of an icon and it is drawn last. 
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E. ICON DATABASE 



NPSNET uses three basic icon formats AN1M, NPSOFF, and DRP binary. The use of standard icon for- 
mats allows the rapid addition, modification, and inclusion of icons. It also provides a buffer from icons in 
different formats, thus we are able to use a wide range of other organizations’ icons by simply writing a con- 
verter into one of the supported formats. These three formats were chosen for their efficiency, availability of 
icons, and the requirements of our sponsors. In addition to the icon description files, an additional ASCII file 
is used to determine which models are to be loaded at run-time. Figure 19 shows a sample of one of these 
files. The lines starting with an O are object header lines. For multi-component models, the F indicates the 
offsets for the origin of the nested frame. For all of the multi -component models, the point of articulation is 
the origin of the nested coordinate frame. The two lines which start with an M are the minimum and maximum 
values for the icon’s bounding box. The line tagged by P indicates if the icon is armed and / or capable of 
resupplying others. By editing this file, it is possible to change the iconic representation of any entity and up- 



date the icon database to represent new entities in the database. 



O defa 001 
POO 

M -1.000001 0.000000 -0.951057 
M 0.999999 2.236068 0.951057 

O defd 100 100 1 
POO 

M -1.000001 0.000000 -0.951057 
M 0.999999 2.236068 0.951057 

O ml 1 101 3 

F 0.000000 1.510000 0.000000 
F 1.655800 0.380000 0.000000 
P 1 0 

M -4.345000 0.000000 -2.240000 
M 5.695801 2.370000 2.240000 

O ml-d 101 101 1 
POO 

M -4.345000 -0.075004 -2.824220 
M 5.028599 3.138165 2.363559 



Model Name, Alive Index, Dead Index, 
Number of Component e 
Capabilities Armed Resupply 
Minimum Bounding Box Values 
Maximum Bounding Box Values 



Offset for First Coordinate Frame 
Offset for Second Coordinate Frame 



Figure 19. Dynamic Entity Definition File 



The Naval Postgraduate School’s Object File Format (NPSOFF), is a text based object and scene de- 
scription language developed at NPS to provide a common icon description format [ZYDA91 BJ. This is the 
format for all of the dynamic icons and a considerable number of the static icons. Figure 20 contains a portion 
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of an NPSOFF icon description. NPSOFF was chosen as the primary model description language for its sim- 
plicity, modeling tools available, and the number of icons available locally, currently in excess of 200. 



defmaterial oowmat 6 
emission 0.000000 0.000000 0.000000 
ambient 0.039216 0.039216 0.039216 
diffuse 0.196078 0.196078 0.196078 
specular 0.000000 0.000000 O. 000000 
ehinineee 0.000000 
alpha 1.000000 
defend 

oetmaterial covmato ^ 
defpoly ^ 

0.000000 1.000000 O . 000000 
4 

-1.000000 1.500000 0.500000 



Material Def init ion 



Setting Current Material 
Polygon Definition 



-1.OOOOO0 1.500000 -0.500000 

1.000000 1.500000 -0.500000 

1.000000 1.500000 0.500000 



defpoly 

0.000000 

4 



1.000000 0.000000 



-1.000000 0.500000 0.500000 
-1.000000 0.500000 -0.500000 

1.000000 O. 500000 -0.500000 

1.000000 0.500000 0.500000 



Polygon Normal 



Number of Vertices 



Vertices 



Figure 20. Sample of an OFF Model File 



The AN1M format was developed at The Visual Systems Laboratory, Institute for Simulation and Train- 
ing, University of Central Florida (1ST/UCF), by Curtis Lisle [TEC92]. Our work in support of DARPA’s 
WAR BREAKER program dictated that we use this format for the Stealth version of NPSNET. It is an ASCII 
based object description format used as the output from IST/UCF’s S1000 database traversal routines. In 
many respects, it is a subset of NPSOFF. It allows only flat shaded polygons in the icons. A short sample of 
an ANIM icon’s polygonal description is contained in Figure 21 . 

Since a considerable number of icons in the world are made up of simple flat shaded polygons, we de- 
veloped a striped down binary version of NPSOFF called DRP. This format differs from the two formats 
above in that it is not only binary, but integral in the file is the world location of the icons. By combining the 
location and description of the icons into a single file, the number and size of the files have been reduced. 
Likewise, so has the flexibility of the datafiles. Since all the polygons, in this format, are simple flat shaded, 
it was possible to optimize the data structure for the SGI GL’s v3f and n3f graphics calls and sort the icon’s 
polygons by color. 
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Number of f . 
Polygons in 
the Model 




df lt_model_l 
27 

255 255 255 

4 

- 0.000003 - 10.000010 16.180336 
9.510556 3.090159 6.180325 
- 0.000006 9.999989 6.180343 
- 9.510570 - 3.090176 16.180342 
255 255 255 0 4 

4 — 



[odel Name 

GB , Shade , and 
Priority Values 



Number of Vertices 



- 0.000003 - 10.000010 16.180336 
9.510569 - 3.090172 16.180338 
0.000006 9.999989 6.180328 
- 9.510559 3.090172 6.180328 
56 199 160 0 5 
3 

- 0.000001 - 0.000003 22.360680 
- 9.510577 - 3.090176 16.180347 
- 0.000003 * 10.000010 16.180336 
200 98 170 0 5 
3 

- 0.000002 - 0.000003 22.360680 
- 0.000008 - 10.000013 16.180340 
9.510563 - 3.090170 16.180328 
- 0.000008 - 10.000013 16.180340 



Vertices 



Figure 21 . Sample ANIM File 



ICON PLACEMENT ON THE TERRAIN 



Assuming the XZ location of the icon is known, the placement of an icon on the terrain is a two step 
process. The first is the determination of the elevation at the desired location on the polygonal skin. The sec- 
ond step is the correct orientation of the model on the terrain. As shown in Figure 22 , the determination of the 
elevation is a straightforward process which has its root in the Gouraud shading algorithm. First, the eleva- 
tions are interpolated along the two of the sides of the terrain polygon. Then a line is constructed between 
these two points and passing though the point in question. The point’s elevation can then be interpolated from 
this line. This process works quite well, but is computationally intensive. To reduce the number of times this 
routine has to be called, the elevations of all static objects are computed once at start up time and then stored. 
In some versions of NPSNET, the static object’s elevations are computed as part of the preprocessing step 
and stored in the DRP format along with the object description. 

When multi -resolution terrain is used, it is possible to end up with flying tanks and trees and tunnelling 
aircraft, as shown in Figure 23. To avoid this, a different elevation determination routine must be called for 
each of the resolutions. The grid elevations, YO, Yl, Y2, and Y3 from Figure 22, are the comers of the 
quadtree level for the selected resolution, Figure 8. This amounts to a “snap to ground” for ground entities. 
This is covered in more detail in the following section, “Placement of Icons on Multiple Resolution Terrain” . 
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/♦Compute the elevation by interpolation*/ 
if x = 0.0 then 

/♦Interpolate along the X axis*/ 

Y = Y0 + ((Y2 - Y0) * Z ) / gridsize) 



XI = gridsize - X 

percentage = X / gridsize 

/♦Compute the elevation along the diagonal*/ 

Y4 = Y0 + ((Y3 - Y0) * percentage) 
if (Z < X) 

/♦Upper Triangle*/ 

/* Interpolate along X Axis*/ 

Y5 = Y0 + ((YI - Y0) * percentage) 
/♦Along the Z axis*/ 

Y = Y 5 + (( Y 4 - Y5) * (Z / X)) 

else 

/♦Lower Triangle*/ 

/* Interpolate along X Axis*/ 

Y5 =Y2 + (Y3 - Y2) * percentage 
/♦Along the Z axis*/ 

Y = Y5 + (((Y4 - Y5) ♦ (gridsize - Z)) / X 1 ) 



grid size 




Figure 22. Generation of Elevations 
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The second step in the placement of icons on the terrain is the orientation of the icon to conform to the 
terrain. Most static objects do not conform to the terrain, rather they sit level. As shown in Figure 24, this can 
result in the creation of a gap between the bottom of the object and the terrain’s polygonal skin. To avoid this, 
we have extended the base of static icon several meters below the origin to compensate for small gaps. Most 
large structures are not built on terrain that has a large pitch and the trees have relatively small trunks so this 
method works well. 





Original Icons Extended Icons 

Figure 24. Correction of Gap Created by Placing Icons on Large Slopes 

The dynamic objects do pitch and roll as they move over the terrain. In reality, they have a suspension 
system that compensates for small deformations in the underlying terrain. However, the correct dynamics 
simulation of a vehicle suspension system is computationally complex. As a result, we treat the vehicle as a 
single rigid body. By ignoring the suspension, it is possible to determine the pitch and roll of the vehicle by 
use the three points shown in Figure 25. The point, Pf, out along the body X axis, determines the pitch of the 
vehicle, while the one along the body Z axis, Ps, determines the roll. The pitch angle is determined by taking 
the elevation of the icon’s origin, Po, and subtracting that from Pf. Then taking the arctangent of the height 
difference divided by the distance from the Po to Pf. The process is then repeated for the roll using Ps. The 
projection of Pf and Ps gives an adequate representation of the orientation of the vehicle for most cases. A 
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more detailed description of the dynamics used in the entity motion routines can be found in Chapter VII EN- 



TITY DYNAMICS. 




G. TERRAIN DATABASE MODIFICATION 

During the course of a battle, the terrain undergoes some changes. Trees get knocked down or blown 
up, buildings collapse, berms are built and breached, and craters form where rounds impact. Combined, these 
actions are what is commonly known as dynamic terrain; modification of the terrain database during the ex- 
ecution of the VW scenario. To allow the database to be modified, the database itself must be built in such a 
manner that a large amount of preprocessing is not required. The run-time structures must be flexible enough 
to allow the addition and deletion of polygons during execution, and the run-time structures must be available 
to the host and the Computer Image Generators (CIGs). The majority of the separate host and C1G configu- 
rations, down load the terrain database from the host to the CIG at the beginning of a scenario. Once the files 
are preprocessed and / or down-loaded, they cannot be modified. It is for this reason that many systems which 
use Binary Space Partitioning (BSP) Trees and separate host / CIG cannot do dynamic terrain. 

As shown in Figure 26, the basic structure of the terrain node in NPSNET has an object pointer which 
points to the static icons in the database. To add an object to the grid square, all that has to be done is instan- 
tiate the object and add the record to the linked list. The next time the grid square is drawn, the updated object 
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is displayed. To remove an object from the database, the reverse is done. The instance of the object is deleted 
from the linked list. Linked lists were used rather than binary trees for the storage of the objects pointers. As 
shown in Table 3, there are relatively few objects in each grid square. We determined analytically that the 
savings in computational cost would not be worth the added complexity of the code for managing the binary 



search trees. 



/♦The obstacle node contains 
struct obelocstruct { 
int type; 
float xloc, zloc ; 
float yloc [4] ; 
struct obelocstruct *next; 



the location and the type of an obstacle*/ 

/♦index into the icon type array*/ 
/♦location of the object*/ 

/♦Elevation of the object 0 high, 3 low*/ 



) ; 

/♦mesh data structure*/ 
struct meehnodetype { 

int color; /*index in the material array*/ 

float elev; 
float normal [3]; 



) ; 

/♦this is the basic array for the map. 

the array is mapgrid [NUMOFGRID] [NUMOFQRID] */ 
struct mapgridetruct { 

struct vehlietsctruct *vehlist; /*liet of vehicles in the grid square*/ 

struct obelocstruct *obetacleliet; /*liet of objects in the grid square*/ 
float elev; /*Grid Post Elevation*/ 

int res level; /* Current Level of detail*/ 

struct meshnodetype meehdata; /‘Struct containing the mesh information*/ 

} ; 



Figure 26. Terrain Node Structure 



There are two basic approaches to modifying the appearance of an object; an object can be scaled, or it 
can be switched out for another model. The use of scaling is particularly useful for things like craters and 
berms that have one basic shape, but vary greatly in size. This allows the use of one icon that can be scaled 
to achieve the desired size. When an icon is scaled, the original icon is left in place and the scale parameter 
is changed for the entire icon. The default value of the three scale values, X, Y and Z, is 1.0 indicating the 
object’s initial size is correct. 

Model switching is used when a model undergoes a major change. An example of this is when a tree 
is blown up and all that is left is the stump. This method has proven to be quite successful when combined 
with the collision detection approach discussed in Chapter VII ENTITY DYNAMICS. While this method 
provides for faster rendering than the scaling method, one less operation has to be performed, it does take 
more memory since there are more icon descriptions are required. 
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Terrain Cross Section 




Figure 27. Determiiiation of the Placement of Craters 

The placement of craters on the terrain is extremely important in the NPSNET VW. As shown in Figure 
27, the elevation of a projectile is checked against that of the ground in every frame. In an early version of 
NPSNET, slow missiles were used and the terrain was relatively flat. This is represented by the lower arrow 
in the figure. Therefore, the crater was placed on the polygonal skin at the XZ location where the missile was 
projected to be at the end of the current frame, Frame T in the figure. This was a crude approximation to the 
location, but it was not a noticeable difference. In subsequent versions, faster missiles and hillier terrain were 
used. It was now much more apparent where the missiles were impacting the terrain. The location error be- 
came quite noticeable, as shown by the upper missile path in the figure. This required that the intersection of 
the flight of the projectile with polygon skin be used to give the true impact point. A binary search along the 
last flight segment can approximate the location of intersection of the missile flight and the terrain quite rap- 
idly. It was now much more apparent where the missiles were impacting on rugged terrain. 

Walters developed a system where bridges, berms and craters could be created and destroyed dynami- 
cally. The icons that he used were a combination of the model switching and scaling methods. This proved to 
be quite easy to implement and produced good results in NPSNET. [WALT92] 
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H. TERRAIN DATABASE MAINTENANCE 



As the VW’s terrain database becomes progressively larger and of higher resolution, the size of the da- 
tabase increases dramatically. While this might seem like a obvious statement, its full impact is not felt until 
large databases are used and the structure of the software has to be changed to support the large databases. 
Table 4 shows the size of a selected few of the gridded databases used in the NFS Stealth system as a function 
of terrain database size. The polygonal databases for the same terrain and post spacing average approximately 
one and a half orders of magnitude larger than the gridded databases. Clearly, the larger databases cannot fit 
entirely into an average size main memory (32 - 64 Megabytes of RAM) with the icon database, program ex- 
ecutable, and locked operating systems pages. Theoretically, the paging mechanism of virtual memory can 
alleviate this by paging the portions of the database in and out of memory. There are two fundamental prob- 
lems with this approach. The first is that the swap space is limited. On most of the SGI workstations in the 
Graphics Laboratory, the system swap space is only fifteen megabytes of disk space. To increase the swap 
space would require the reformatting and partitioning of the disk. Even increasing the swap space and real 
memory, the databases will eventually exceed the capacity of the machines. The second problem, assuming 
enough swap space and main memory, is the paging algorithm used. The machine does not pull a page into 
memory until an attempt is made to access it, basic demand paging. The problem with this is that for time 
critical systems, such as a VW, this introduces an unacceptable and unpredictable delay into the system. 



Table 4: TERRAIN DATABASE SIZE 



Database Name 


Size 

(Kilometers) 


Post spacing 
(Meters) 


Size 

(Grid posts) 


Number of 
Grid posts 


File Size 
(Kilobytes) 


Fort Irwin 


6X7 


5 


1388 X 1431 


1 ,986,228 


65,546 


Fort Irwin 


54X54 


125 


433X433 


187,489 


6,187 


Nellis AFB 


177 X 111 


500 


355 X 223 


82,715 


2,730 


Fort Hunter-Liggett 


50X50 


125 


401 X 401 


160,801 


5,306 


Northwest Iraq 


274 X 115 


125 


2193 X 921 


2,019,753 


66,652 


Northwest Iraq 


274 X 115 


250 


1097 X 461 


505,717 


16,689 


Northwest Iraq 


274 X 115 


500 


549X231 


126,819 


4,185 



We took two basic approaches to addressing the database size problem, one for gridded terrain in 
N PS Stealth and a separate one for the polygonal terrain in NPSNET. The two methods share a common ap- 
proach, that of implementing predictive paging of the terrain database. Predictive paging, also known as op- 
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timal paging, differs from demand paging on when the pages are brought into memory. As stated above, 
demand paging brings the page in when it is referenced, thus creating a delay in the execution. Predictive pag- 
ing brings the page into memory before it is referenced. For the terrain database, the logical page, the amount 
of information brought in by the user as opposed to the physical page which is system dependent, is called a 
load module. The load module is the smallest unit of the database that can independently addressed. For the 
gridded terrain, it is a single post, whereas for the polygonal terrain, the load module is the quadtree rooted 
at the kilometer post. 

To continue with the operating systems analogy, the working set of the terrain database is the active 
area. Figure 28. The bounds of the active area can be determined by sweeping the field of view one complete 
horizontal revolution around the location of the eyepoint. Any grid square contained in the area covered by 
the sweep is part of the active area. The size of the active area allows the user to swing his view around in 
360 degrees without any database paging. To account for the predictive paging algorithm, to page in terrain 
beyond the field of view, and simplify the paging algorithm, the active area was increased in size from a circle 
with a radius of one view distance to a square with a side length of two times the view distance plus two load 
modules. Figure 28 shows the relationship of all of the geometric components in the determination of the ac- 
tive area. 
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To maintain the active area current, including the predictive paging portion, in NPSStealth a separate 
database management process is spawned. This process is only spawned when there are sufficient CPUs 
available on the workstation. On a single processor workstation, the additional overhead and delays intro- 
duced by the database management process are higher than the delays created by the system’s paging algo- 
rithm. Using shared memory, the management process creates an active area slightly larger than described 
above. The additional area is added to the major direction of travel, the next area expected to be brought in. 
The database management process then enters a nested loop and references all of the grid posts in the com- 
puted area. Since the SGIs use First In, First Out (FIFO) memory page management, all of the grid posts in 
the active area have been recently referenced. Those not currently in memory are paged in at this time. The 
grid posts that are paged in are on the forward edge of the direction of travel and outside of the field of view. 
Thus, rather than having the rendering process wait on the grid posts being brought into memory, the main- 
tenance process waits. After a traversal is completed, the process then sleeps a short period of time. By sleep- 
ing, the management process frees up the CPU for other tasks much like the standard UNIX demons. The 
length of time the process is put to sleep is dependent on the velocity of the player. The slower the player 
moves, the fewer grid squares it will traverse per unit time, and the longer the process can sleep. 

To make this work, the management process must treat the grid posts as if they were in main memory. 
As noted above, the terrain database does not all fit into main memory. To get around this limitation, the ter- 
rain datafile is defined and constructed as a memory mapped file. This is a file that is stored as a “memory 
image.” The data is physically stored the same way it would be in main memory. The base of the file is given 
an offset in memory and the file is then treated as if it was real memory. The operating system manages the 
paging of the data from the file much the same way it manages main memory paging. In essence what was 
done was to increase the swap space of the system by making the datafile a swap space. There are three dis- 
advantages to this approach. The first is the added level of indirection in the operating system paging of the 
data. This is easily overcome by the use of the predictive paging process described above. The second draw- 
back is the added complexity in the addressing scheme. Since the pointer to the base of the file is a one di- 
mensional array pointer, the 2D address mapping function has to be coded by the programmer. This is easily 
coded mto a macro that abstracts out the details and improves readability of the code. The final drawback is 
when an NFS mounted file system is used. Not only is there the delay in the paging of the data, but the net- 
work delay and bandwidth limitations now become a factor. The use of memory mapped files works quite 
well on the SGI, but it limits the portability of the code to other platforms. 
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The polygonal terrain has a different structure and hence a different access method. As stated above, 
the polygonal terrain database is partitioned into an array of four level quadtrees. It is possible to take advan- 
tage of this structure by making each of the load modules equal to one of the quadtrees. The basic structure 
of the quadtree file is shown in Figure 29. Since all of the Polygon Count and Index arrays are of the same 
size, they can be read in a single read. Along with the arrays, a total polygon count is also read in. This deter- 
mines the size of the read buffer and the polygon data. Since the Count and Index arrays are a constant size, 
there is no need to free them to reallocate the memory. Rather, all that is required is the reassignment of point- 
ers to the arrays. Since the polygon count varies, the memory space is freed and reallocated for each of the 
polygon array reads. The determination of optimal quadtree size was driven by the graphics, network, perfor- 
mance, and common military usage. In our sample databases (Fort Hun ter- Liggett, Fort Irwin, and The Fulda 
Gap), a four level quadtree file was less than two kilobytes in size. This small size allowed the information 
to be read in two Network File System (NFS) reads, the limitation on the size of Ethernet packets being the 
determining factor. The next larger files, 2000 meter based nodes, were going to be over four times as large. 
In terms of graphics performance, a 1000 meter polygon provides the same cover as sixty-four 125 meter 
polygons. Experimentally, we determined that the use of 2000 meter polygons did not add much to the scene, 
in some instances there was a noticeable and disconcerting distortion of the terrain, and the graphics perfor- 
mance was not increased a significant amount. The use of 1000 meter grid squares is also a function of the 
common use of one kilometer grid squares in military operations. While the 500 meter based quadtree files 
were smaller and each of the two reads was faster, we could add another level of resolution, and improve the 
graphics performance, without impacting the network or disk loading due to the buffer and packet sizes. 

To manage the reading in of the load modules, four separate processes are spawned. Each one of these 
processes is responsible for the paging of the terrain in one of the cardinal directions (north, east, south, west) 
and freeing the memory in the opposite direction. To determine which, if any, load module is to be paged in, 
the concept of a bounding box is used, Figure 30. The vehicle is initially centered in the middle of the box. 
When it gets to one of the edges of the bounding box, the next strip of load modules is read off the disk, Figure 
31. The main application process monitors the location of the vehicle within the bounding box. When the ve- 
hicle goes outside the box, the main process increments the semaphore. This unblocks the reading process for 
that direction and the next strip of terrain is paged in while the previous one is paged out Since the terrain 
pages are read only, they are not written back to disk. Once the paging of the strip has been completed, the 
process blocks itself. Then a new bounding box is created at the next load module boundary. As shown in 
Figure 30, the bounding box is larger than the size of the load modules. The overlay created by the size dif- 
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ference, in this case 100 meters, provides a buffer zone where the vehicle can move back and forth without 
causing thrashing of the load modules. On a IRIS 240/VGX, a player can travel approximately 2000 kilome- 
ters per hour before the paging of the database becomes visually noticeable. 



I. SUMMARY 

In this chapter we have presented the two of the three databases used in NPSNET and how they are for- 
matted and maintained. Combined together, the features presented in this chapter form the core of some of 
the unique aspects of NPSNET. Being able to simultaneously do terrain paging, terrain and object level of 
detail, and dynamic replacement of icons at run-time put NPSNET in the forefront of simulation technology. 
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Figure 30. Bounding Box Used for Terrain Paging 
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VI. STRUCTURE OF THE SOFTWARE 



Almost all VW systems have a common software structure. This structure is dictated by the basic func- 
tions of a VW system. These functions are: to receive input, construct a representation of the world, and dis- 
play the result to the user. The basic run-time structure of all networked VW systems is shown in Figure 1. 
Obviously, the network management process is not needed if the VW is not part of a network. Not shown in 
this diagram is the start up process. The Start-Up process reads in the data and constructs the world before 
control is passed to the processes in Figure 1. The remaining processes are part of what is known as the input 
/ compute / draw loop. A conceptual sequencing of the processes in contained in Figure 32. The Dynamics 
and Scene Management processes are combined into the Compute process in the figure. The Renderer process 
(software) is combined with the graphics pipeline (hardware) to form the Draw process. This chapter serves 
to present an overview of the structure of the software. We also discuss the implications the parallelization of 



the software. Specifically, we focus on the sequencing and interconnection of the component processes. The 
processes are covered in more detail in the following chapters. 



Time 




Figure 32. Conceptual Sequencing of the Processes 
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As discussed earlier in "MACHINE LIMITATIONS", there are more processing requirements m a 
complex, populated VW than a single CPU can handle. To get around the current limitations of a single pro- 
cessor, there are two possible courses of action: Get a faster processor or use more than one processor. 

While using a faster processor will speed up the execution of the system, there are a few real world con- 
siderations that have to be taken into account. The first of these is the operating system. SGI’s IRIX is a der- 
ivation of UNIX. As such, there are a considerable number of demons running as part of the operating system. 
These demons run at seemingly random times for varying lengths of time. If the machine has a single proces- 
sor, the demons will have to share it with the VW system. The net result of this is that the user perceives a 
skipped frame or stutter. The frame rate will be fairly constant, or changing smoothly, and then all of a sudden 
the display will freeze for a brief period of time while the demons run. If a real time clock 1 is used, all of the 
entities will jump to their correct locations during the next frame. This gives the impression of a dropped 
frame. 

In network VWs, a more fundamental problem exists with the use of a single processor. When Protocol 
Data Units (PDUs) arrive at the node from other nodes they must be buffered. Depending on the buffer size 
of the network interface card and the network loading, data is lost if it is not processed or buffered as soon as 
it arrives at the node. Most UNIX network interface drivers can buffer a single message. As a result, if two 
PDUs are received during a single execution loop of the system, one of the messages is lost. An interrupt han- 
dler can be constructed to buffer the incoming messages. However, this will have the same effect as the UNIX 
demons on the frame rate. To process the PDUs in the application, the interrupts will have to be disabled to 
prevent corruption of data, once again allowing an opportunity for a message to be lost 

The other option is to execute a portion of the code in parallel on multiple processors. On a two proces- 

sor system, a single threaded VW system does not necessarily suffer the same delay imposed by the demons 
as if it were running on a single processor system. In such a system, the demons run on the second processor. 
There is the same problem with the network management. The only way to avoid the problem with losing 



1. For our purposes a “real-time clock’ 1 is synonymous with a wall clock. Time is measured in a 
monotonically increasing manner corresponding with real time. This is different than a CPU clock 
which measures the amount of CPU time that was used by a process, or a timed frame clock where 
each frame is assumed to take the same amount of time, both of which can result in the perceived 
speeding up or slowing down of the controlled entity. The speed of the clock can be faster or slower 
than real-time as long as it has constant intervals. The reference time for the clock can be set or 
reset at the user’s discretion. 
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PDUs from the network is to have a process that listens to the network and buffers the messages for later re- 
trieval. The PDUs can then be processed by the application in the appropriate place in the control flow. 

Even as processors get faster, which they inevitably do, the computational requirements of the VW will 
continue to exceed the capabilities of a single processor. As with almost all systems, there is a bottleneck in 
the VW architecture. In all of the NPSNET systems, as well as many others, it is the rendering process that 
is the limiting factor on the frame rate. To reduce the impact of this, a considerable amount of resources are 
given to the rendering process. In addition to the graphics pipeline , a CPU should be devoted to the rendering 
process. This is what has been done in NPSNET. The impact of the parallelization on the frame rate was min- 
imal, only one to two frames per second, but we were able include real-time contact detection, double the 
number of entities to 500, and use more realistic dynamics later without impacting the frame rate on a SGI 
240/VGX. When the resulting system is run in the single thread mode, not only do we lose the benefit of the 
parallelization but the additional computational load costs about another frame per second. As we can see, the 
isolation of the bottleneck process allows us to improve the actions of the VW without affecting the frame 
rate or the realism. The rest of this chapter covers the inherent parallelism in a ground combat VW in specific, 
gives an overview of what each process does, and then ties diem all together by discussing the sequencing 
mechanisms needed for efficient operation. 

A. INHERENT PARALLELISM 

As discussed above, the network and graphics processes are obvious candidates for parallelization. 
These are not the only tasks that can be performed in parallel. The motion of the individual players is also 
done in parallel. On the macro level, this is done via separate nodes on the network. At the micro level, the 
player action loop can be parallelized. It is at this level that we have to be concerned with coarse versus fine 



2. A processing thread is an execution stream running at a given moment. A single threaded process 
has one flow of control in the program and hence only one portion of the code is being executed at 
any given instance. A parallel program has multiple threads and might have several different or the 
same portion of the code being executed at any given moment by the different threads. Threads can 
be created, or spawned, and terminated, or killed, once or multiple times during the execution of the 
program. The threads can share all, some or none of the following: memory space, file descriptors, 
interrupt routines, I/O devices, and processors. 

3. The graphics pipeline is the integral set of hardware that is comprised of the polygon engine and 
the pixel managers, or raster engine. This portion of the hardware, when in a separate box, is often 
called the Computer Image Generator (CIG). Its function is to take the graphics primitives passed 
by the CPU, or host, and convert them to pixels on the screen. Most modem systems have a consid- 
erable amount of parallel hardware to accomplish this, we will not discuss it further. For more 
information, refer to [AKEL88], [FUCH89], [E&S92], and [E&S91]. 
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grain parallelism 4 . All of our workstations are members of the SGI IRIS 4/D series. As such, they have MIPS 
processors. These are complete microprocessors that function best in a multi-instruction, multi-data (MIMD) 
configuration. Also there is a significant overhead on the creation and management of new threads with such 
systems [SGI91a]. It is these hardware constraints that forced us to use the coarse grain parallelization para- 
digm in NPSNET. Even with these limitations, a significant amount of computation and rendering can be 
done in parallel. This allows us to redraw Figure 32 as Figure 33. The vertical axis is time, blocks shown at 
the same level are done in parallel. Horizontally across the picture are the tasks. 



Time 




Figure 33. First Level Parallelizaton 



Since the distances the players move is relatively small. Table 1, it is possible to run the ballistic com- 
putations before the player motion routines. Likewise the selection of the view volume is independent of the 
movement of the ballistics, so these can be done in parallel as well. Figure 34 shows the resulting structure 
of the software. It is a further refinement of Figure 33. The Compute process has been broken down into the 
movement and contact detection routines which make up the Dynamics process and the Scene Management 



4. There is no clear cut differentiation between coarse and fine grain parallelism. There is a grey 
area that can be considered both. The definition that we use for fine grain parallelism is the parallel- 
ization of loops. This is also known as homogeneous parallel programming. Heterogenous parallel 
programming, or coarse grain parallelism, is the breaking up of dissimilar blocks of code to run on 
separate processors. 
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Process. Likewise, the Rendering process has been broken down into three component parts. Not shown in 
the figure is the clearing and preparation required by the Rendering process each frame. 




Figure 34. Second Level Parallelization 



B. TASKS 

We have been discussing the tasks performed by each of the process blocks in the abstract sense. In this 
section, we discuss them in a functional manner, what they have to do. Where significant research was done. 
Dynamics, VW Population, Scene Management, and Network Management, the procedural discussion is cov- 
ered in the following chapters. The other tasks. Start Up Process, User Input Management, and Rendering, 
are covered in slightly more detail in this chapter only. 

1. Start Up Process 

The start-up process’s main function is the configuration of the VW in preparation for the input / 
compute / draw loop. The functions that have to be performed are shown in Figure 35. While all VW systems 
have the same basic requirements for configuration, we cover the NPSStealth’s start up process in detail. This 
is the most complex and flexible of all the systems we have built and as such requires more from the start up 

process. 
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Figure 35. Start Up Process Functions 



Part of the flexibility of the VW comes from the ability to pass command line switches to the ini- 
tialization process. The switches provide a means to alter the default configuration of the system. These in- 
clude things like the network interface, terrain database, icon files, and image parameters. Since the switches 
set the values of the internal flags, this reading and processing of the switches is the first step in the start up 
process. 

The next step is the initialization of the graphics subsystem. Naturally, the detail of the initializa- 
tion of the graphics subsystem is dependent on the type of equipment used. There are certain high level tasks 
that are common to all the systems. These include things like the allocation of bit planes, window configura- 
tion and opening, construction of the color maps, and configuration of the interaction devices. For more spe- 
cific information on the configuration of the graphics process, refer to a graphics programmer’s guide such 
as [SGI91B]. The initialization of the graphics subsystem allows messages to be displayed concerning the 
status of the start up process. This is a very important feature, since the set up process can take a considerable 
amount of time. If users are not provided feedback on the status, they might think the system has crashed. 

The Terrain Configuration File, Figure 36, contains the database dependent information. By read- 
ing this data in from a file, the system can be configured at run-time to use different databases representing 
different parts of the world at varying resolutions. The file is formatted so that there is a text string identifying 
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the purpose of the variable and the variable name on the line above the data. The first parameter is the max- 
imum viewing distance. It is used in the construction of the view triangle and is covered in detail in Chapter 
IX The next four data elements specify the coverage of the database. The first two are in kilometers and are 
used for human readability. The system itself uses the next two which specifies the number of grid posts in 
the X and Z direction. These values are used to do boundary checking and to determine the size of the memory 
mapped file. The grid size, or post spacing, is expressed in meters. The remaining file entries are all file names 
of the files that contain the desired database components. The first of these is the elevation post file. This is 
the only required file. Rather than being read in, the file is memory mapped to make it appear that it is an 
extension of the virtual memory system. The road file contains the polygonal description of the road seg- 
ments. The next entry has not been implemented yet. This is the file that will contain the micro-terrain poly- 
gons for stored terrain deformations. The keyword “NULL” indicates that there is no file associated with this 
entry. The remaining two files contain the location of the objects on the terrain. The first one is a binary file 
that contains the iconic description of the objects and the instances of the object in a single file. The second 
file is an ASCII file of the object locations. By using two files to contain the object locations, we have 
achieved a compromise between speed and flexibility. The binary file can be read in faster and is more com- 
pact, while die ASCII file is easier to add, modify, or delete instances. The purpose of having the configura- 
tion file was to store the database parameters outside of the program so that a single executable can use 
multiple databases. We were able to do this without a loss of efficiently. 

The next function of the Start up process is the allocation of memory for the terrain database. The 
icon and entity databases are a static size and the memory space is allocated at compile time. The memory 
mapping of the terrain is done using the code in Figure 37. The advantages of using a memory mapped terrain 
database are discussed in the preceding section, "TERRAIN DATABASE MAINTENANCE". The drawing 
buffers, discussed in more detail in Chapter IX, are allocated as a two dimensional arrays using the code in 
Figure 38. It is important to note that the resulting array is not in a contiguous memory space. Due to the na- 
ture of the malloc command, the array might be spread out over the entire data space. This is especially im- 
portant when doing non-two dimensional array indexing operations. The use of dynamic arrays allows the 
flexibility to have different viewing distances and database sizes with very little loss of efficiently. 

The reading of the road polygon file completes the polygonal skin of the terrain. As mentioned in 
Chapter V, the road polygons are stored as a linked list hanging off of the appropriate elevation post. As the 
polygons are read in, the memory is allocated dynamically as the lists are built This allows the user to deter- 
mine if roads are needed at run time. 
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Default view distance (VIEWDIST) 

10000 

Number of kilometers east-west (NUMOFKMX) 
274 

Number of kilometers north-south (NUMOFKMZ) 
115 

Number of grids east-west (NUMOFGRIDX) 

549 

Number of grids north-south (NUMOFGR1DZ) 

231 

Gridsize (GRIDSIZE) 

500 

Elevation Datafile (B1NARYELEVFILE) 
/work/data/nwiraq4/datafiles/nwiraq500.mesh 
Road datafile (ROADFILE) 
/work/data/nwiraq4/datafiles/nwiraq500.roads 
Terrain data path (DATAPATH) 

NULL 

Object Data (OBJECTSPATH) 

NULL 

Special Object Data file (OBJECTSPATH) 
/work/data/n wiraq4/datafi les/n wiraq .obj 



Figure 36. Terrain Configuration File 



/♦Create file handle*/ 

diit_fd=open( B1 N AR YELEVF1 LE.O_RDONLY); 
if(dirt_fd — -1){ 

printf(“Unable to open the terrain file %s\n”,BINARYELEVFILE); 

printf( M Error # % 1 d “,ermo); 

fflush(stdout); 

perrorC"); /*print out system text message*/ 
exit(0); 

} 

/♦compute the file size*/ 

fsize = sizeof(MAPGRIDSTRUCT)*NUMOFGRIDX*NUMOFGRIDZ; 

/♦memory map the file, mapgrid is the pointer to the base of the file*/ 
mapgrid = mmap(0, fsize, PROT_WRITE,MAP_PRIV ATE, dirt_fd,0); 
if((int)mapgrid < 0){ 

/♦an error occurred*/ 

printf( M Memory map error number %d **, eirno); 
ffiush(stdout); 

perror(“”); /*print out system text message*/ 
exit(0); 

} 



Figure 37. Memory Mapping the Elevation File 
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/♦since we only care about the stuff that is offset from the minx, minz to maxx, maxz we don’t have to allocate 
draw buffer space for the entire grid matrix, but rather a VIEWDIST by VIEWDIST matrix. To this let’s add a 
little fudge factor, how about 1.5 VIEWDIST?*/ 
buffdim = (int) 1.5*(VIEWDIST/GRIDSIZE); 

/♦allocate the memory for the buffers*/ 
for (jx=0;jx<NUMOFBUFFERS;jx++){ 

/♦allocate the x direction*/ 

if((displaybuffer(jx].terrain.drawarray = 

(BUFFERELEMENT **)malloc(sizeof( BUFFERELEMENT *) * buffdim)) = NULL){ 
printf( a Unable to malloc displaybuffer[%ld].terrain.drawarray\n” jx); 
exit(O); 

} 

/♦and each of the Z columns*/ 
for (ix = 0;ix<buffdim;ix++){ 

if((displaybuffer(jx].ten-aiii.drawaiTay[ix] = 

(BUFFERELEMENT *)malloc(sizeof(BUFFERELEMENT)*buffdim)) = NULL){ 
printf(“ Unable to malloc displaybuffer[% 1 d]. terrain. drawarray[%ld]\n”, jx, ix); 
exit(O); 

} 

} 

} 



Figure 38. Allocation of Database Specific Sized Drawing Buffers 



In the NPSNET system, the quadtree polygonal data files are used instead of the memory mapped 
terrain file. In NPSNET’s Start up process, the terrain data structures described in Chapter V are allocated 
and filled. The quadtree files that make up the active area are read in and the hot box is initialized with the 
assumed position of the driven entity being the center of the database. At this time, the semaphores to control 
the terrain paging and the paging processes are created and immediately blocked. 

NPSOFF is a general purpose icon description file format developed at the NPS [ZYDA91 B J. One 
of the things it does especially well is the definition of lights and materials. Taking advantage of this, we 
chose to use the NPSOFF file format for the storage of the lights and the materials used in the NPSStealth. 
Likewise, NPSOFF was used as the primary icon format for all of the objects in all of our systems. The use 
of a standard icon format is critical to the successful population of a VW. The actual construction of the icons 
is tedious and time consuming, it much easier and faster to use a model that has already been developed. The 
list of icons to be loaded is contained in an ASCII file the user can edit. This allows the user to select the 
number and types of icons required for the particular V W he is planning on using. Once again, the use of ex- 
ternal ASCII configuration files provides an ability to tailor the initial population of the VW to the applica- 
tion. 
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The material cross reference file, Figure 39, serves several different functions. The first of these 
is the reduction of the size of the terrain files. The is done by storing the two thirty-two bit colors for the upper 
and lower triangles in the cross reference array and only the index, an eight bit char, in the terrain file. While 
this increases the cost of binding a color by one indirection, the size reduction of the data structure allows for 
better cache performance. The file also contains the texture and material identifiers for the specific terrain 
type. By having this in a central file, we can avoid duplication of storage and initialization. A further function 
is the ability to reconfigure the appearance of the terrain. Since a cross reference acts as a central mediator of 
the colors, by changing the values in the file the appearance of the terrain can be changed. 



Dirt 


NPSJD SIMNETJD Color upper/lower Material 


Sandy Jiardpacked_soil 


0 102 


FF2D83BE 


FF5483BE 


12 


agricult ure_-_brown_&_green 


1 83 


FF2E5D59 


FF1E4F49 


17 


agriculture_-_brown 


2 24 


FF2E4159 


FF1E3149 


10 


agriculture_-_brown 


3 82 


FF2E4159 


FF1E3149 


10 


Green _ground_cover 


4 57 


FF004300 


FF005300 


19 


Residential/industrial 


5 120 


FF737373 


FF8B8B8B 


4 


Impassable_water 


6 43 


FF460000 


FF910000 


14 


Cement 


7 129 


FF737373 


FF8B8B8B 


4 


BUG_Sandy 


80 


FF2D83BE 


FF5483BE 


12 


m 


Road 


NPS 1 


ID SIMNETJD Color Material 




Railroad 


0 15 


FF222222 


5 




Paved_Road 


1 129 


FF000000 


1 




DirtTrail 


2 27 


FF1E3149 


6 




Pipeline 


3 102 


FF22227f 


9 




Airstrip 


4 72 


FF101010 


1 




m 


Fences 


NPS 1 


ID SIMNETJD Color Material 




Picket 


0 15 


FFFFFFFF 


2 




Panelled 


1 109 


FF5991C5 


2 





Figure 39. Material Cross Reference File 



The texture identifier values from the material cross reference file, Figure 39, are used as the key 
for binding the textures during run-time. The texture identifiers correspond to the S1MNET polygon identifi- 
ers and are labeled SIMNETJD in the datafile. The textures are drawn from a palette of approximately one 
hundred and fifty textures that came from a multitude of sources. By assigning each texture a unique number, 
we can read in only the textures required by the models or terrain. The same rationale is applied to the material 
identifiers in the file. 

As discussed in [A1RE90A], the availability of a 2D map is helpful for navigational tasks. We 
have found that the 2D map is also useful as a mechanism for the determination of the location of the driven 
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entity in relationship to the other players. To facilitate the visualization of the other players and the terrain 
features, the map has multiple scales. The five scales are full, half, quarter, eighth, and sixteenth scale. The 
full scale map contains the entire database at a lower resolution, every fourth grid post is used as a mesh ver- 
tex. This is done to reduce the polygon count and the time it takes to render the map. Polygon reduction is 
also applied to the half and quarter scale maps. Since the higher resolution maps do not display the entire da- 
tabase, some means of database windowing had to be done. To accomplish this, we implemented the algo- 
rithm in Figure 40. When a resolution is selected, the driven entity is located in the center of the map. The 
east-west and north-south limits are then determined by the resolution scale and the location in the database. 
The map stays fixed until the driven entity moves out of the inner box, at which time a new map is created 
reflecting the new position of the driven entity. The overlay planes are used to display the location of the ac- 
tive players in the world. Since the map remains static and only the players icons change from frame to frame, 
redrawing only the icons reduces the graphics requirements. In order to give some appreciation for the con- 
tour of the terrain, the terrain is elevation shaded using the algorithm in Figure 41 . This results in the lowest 
elevation being black, while the highest is white. With Fort Hunter-Liggett and Eastern Saudi Arabia - Kuwait 
- Iraq (East S AKI), databases we found it particularly useful to shade the zero elevation, mean sea level, to 
blue to represent the ocean. 



/♦Figure out what area we are going to draw*/ 

left = pos[X] - MAPSIZEX/scale; /* Entity position - Size of the database along the X axis / Zoom Factor*/ 

right = posfX] + MAPSIZEX/scale; 

bottom = pos[Z] - MAPSIZEZ/scale; 

top = pos[Z] + MAPSIZEZ/scale; 

if (left < 0){/* The desired map extends off to the left (West) of the database*/ 

right -= left; /* Shift the map to the right by the amount it goes negative*/ 
left = 0.0; 

} 

if (right > MAPSIZEX){/*Right (East) Overlap*/ 
left -= (right - MAPSIZEX); 
right = MAPSIZEX; 

} 

if (bottom < 0){/* Bottom (North) Overlap*/ 
top -= bottom; 
bottom = 0.0; 

} 

if (top > MAPSIZEZ){/*Top (South) Overlap*/ 
bottom -= (top - M APSIZEZ); 
top = MAPSIZEZ; 



Figure 40. Map Centering Algorithm 
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/*Build the color step. This is done once at set up*/ 

/*If we use too many colors it doesn’t look good, a COLORSTEP of 16 looks good*/ 

colorstep = (max_elevation - min_elevation)/COLORSTEP;/* elevation range of each color band*/ 
colordelta = 255/(COLORSTEP +1 ); /* Differences in color for each color band*/ 

if (GETELEV(ix,jx) = 0.0) {/* treat zero Elevation as the Ocean*/ 

RGBcolor(0,46,l 13); /* a nice blue color*/ 

} 

else{ 

/♦interpolate the color of the elevation point*/ 

colorint = (int)(colordelta + colordelta*(ELEV(ix,jx) - min_elevation) /colorstep)); 

/*use a grey scale color ramp*/ 

RGBcolor(colorint, colorint, colorint); 

> 



Figure 41. Construction of Grey Scale Elevation Shades 

The final step is the set up process in initializing the network. What is involved in the connection 
and set up of the network is discussed in detail in Chapter X. The reason that the network connection is the 
last step in the set up process is two-fold. The first of these is network consistency. If the system terminates 
before completing initialization, but after it has connected to the network, all the other nodes on the network 
will have corrupted databases reflecting the receipt of a PDU from a node that is not on the network. By con- 
necting the last thing, all of the other functions have completed successfully. The second reason is the storage 
of the PDUs. The system uses a fixed buffer size that is based upon the expected worse case frame rate and 
the estimated network load All of the PDUs from the time the network has been connected until the first 
frame will have to be buffered. Since the set up process can take a considerable amount of time, this could be 
a considerable number of messages. Faced with this, the buffer will have to be artificially large to support this 
artificial one time peak load or discard PDUs. Rather than doing either one of these, we chose to make the 
network connection the last thing done in the Start up process to minimize the time, and thus the number of 
PDUs, outside of the main loop. 

2. User Input Management 

The user input management process is the primary means of inputting data into the system during 
execution. The data corresponds to the user’s control input of the entity. As shown in Figure 4, NPSNET has 
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a rich selection of user input devices. The input from each of these devices has to be managed in a way that 
is consistent with the device. For example, the up arrow key and SpaceBall forward both result in the entity 
going faster. However, the up arrow key, a “button” device, returns zero or one, and the SpaceBall, a “valu- 
ator” device, returns a range of values based upon the user’s actions. In this case, the up arrow key adds five 
meters per second to the speed, while the input from the SpaceBall is scaled by the user selected sensitivity 
factor and then added to the speed. This brings up an interesting point. In N PS NET, the user controls the lo- 
cation of the entity by controlling the acceleration. By this we mean, that the entity’s speed is assumed to be 
constant without user input When the user lets go of the SpaceBall or stops pressing the up/down arrow keys 
the speed remains constant. This was done to prevent user fatigue of having to consistently hold down a key 
or continually press on the SpaceBall. 

There are two fundamentally different ways of getting the information from the device into the 
system. The first of these is polling. Polling, the querying of the device status, is used only in the demonstra- 
tion version of NPSNET to get the position and orientation of the Ascension Bird. This special case device is 
the only one that is currently used that is not supported by the SGl’s built-in input queueing mechanism, the 
second method of inputting the values into the system. As shown in Figure 42, when the user performs an 
action, the operating system passes the action through a filter. If the action is one that the developer has spec- 
ified and the focus of input is into the system, it is passed through the filter and put on the queue in the device 
and value format. When the system reaches the input routines, the queue is read for all the stored input values. 
This input paradigm is fundamentally identical to the structure of the network process, both use asynchronous 
buffered input. The structure of the network process is discussed in detail in Chapter X. 

Additional in-depth treatment of user interfaces, beyond what has been said above, is necessary to 
fully appreciate this critical topic. [LAUR90] is a fine text that provides a good overview of user interfaces. 
NPSNET uses the vehicle metaphor paradigm described in [WARE90] to control the entities. For more spe- 
cifics on a particular paradigm or methodology, see [CHAP92], [MACK90J, [ROBI92], [WENZ92], and 
[SUTH65] all of which provide an interesting perspective into user interfaces for a VW. 

3. Entity Dynamics 

Entity dynamics is the science of modeling the motion of vehicles in their operating environment. 
In NPSNET, there are three fundamental kinds of dynamic entities: air, ground, and sea. Each of the three 
types have their own dynamics routines. This is a result of the differing environments that the entities operate 
in. The aircraft are not concerned, for the most part, with collisions with ground based objects, but do have 
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Figure 42. System Queue Filter 

three dimensional movement. The ground based player’s orientation has to conform to the terrain surface and 
ground entities have to react to collisions with ground based objects such as trees. The third category of play- 
ers, ships, are a mixture of the two. They conform to the surface, but they do not have to do contact detection 
with the objects on the terrain. All three categories do share the requirement to respond to collisions with other 
players and the fourth type of player, the weapon. NPSNET’s weapons are in reality special cases of air en- 
tities that have simplified dynamic models and extended contact detection algorithms. Entity dynamics is dis- 
cussed in more detail in Chapter VII. 

4. Scene Management 

The primary function of the scene management routines is the composition of the image that is 
presented to the user. As discussed above, this requires a trade off between image quality and speed. The key 
concept of scene management is to determine if is it faster to exclude a polygon from the rendering process 
or to let the rendering process handle it. As discussed in detail in Chapter IX, there are several components 
to the construction of the image. The first of these is the determination of the view volume, or what and how 
much do we see. This can further be broken down into where in the database is the eye point and where are 
we looking, or the eye point controls, and what part of the database is in our horizontal and vertical fields of 
view (fov). The second is at what fidelity, or level of detail (LoD), do we see the objects that comprise the 
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image. Once the eye point has been positioned and the appropriate icons are selected, a data list is prepared 
for rendering traversal. The construction of the rendering list can be done as part of the culling or the entire 
list could be created before it is passed to the rendering process. Likewise, the rendering list can take any one 
of several forms depending on the machine and system architecture. The simplest type of list for the renderer 
and the most complex for the scene management process is a transformed primitive list. At the other end of 
the spectrum is the rendering list which is made up of the entire database. Since fine grain, or window, clip- 
ping is done by the renderer, it is possible to dump the entire VW database into the rendering process and let 
the hardware clip out what is not visible. The key purpose of the scene management routines is to find the 
cross over point between the two methods. Chapter IX discusses the trade-offs involved and the methodolo- 
gies needed to efficiently construct a useful rendering list 

5, Rendering 

Rendering, or drawing, involves the transformation of the graphics primitives selected by the 
scene management process into pixels on the screen. Since the discussion of the data structures and rationale 
for them are discussed in detail in Chapter IX, they are only touched on lightly here and presented solely in 
the context of the rendering process. The rendering process is a two part operation. The second part of the 
rendering process is the actual transformation of the primitive into a lit, shaded, textured, Z-buffered pixel. 
This is fundamentally a hardware process and is not discussed any further in this dissertation. 

The first part of the rendering process is the traversal of the rendering list to extract the graphics 
primitives. The display buffer, bufftype, shown in Figure 43, is the key to the database traversal process. At 
first glance, the structure seems to be extremely inefficient in terms of memory utilization. Considering the 
fact that we use two display buffers, it seems even worse. However, what we did was sacrifice memory to 
gain speed. By using this type of structure, we are able to reduce the amount of the database the renderer’s 
traversal routines are required examine. The rationale behind having two display buffers is shown in Figure 
44. Based upon our empirical studies on an SGI 120/GTX, 240/VGX, and 320/VGX, the rendering process 
takes considerably more CPU time than the other processes. As such, we want to have the data available for 
it ready whenever it completes rendering the current frame, while at the same time preserving the original 
data so the next frame can be computed and stored in the other display list buffer. The net result of this is the 
producer - consumer relationship shown in Figure 44. 

The actual traversal of the display buffer is a multistep process. Figure 45. The first step is the ren- 
dering of the polygonal skin of the terrain. To do this, the “terrain. drawarray” is traversed in a nested loop in 
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/♦used to build lists to pass to the display process*/ 

/♦draw (0 to vehcount), don’t draw (notshownveh - (MAXVEH -1)) */ 
struct drawlisttype { 

VEHPOSTYPE thedrivenveh; 
int vehcount; 
int notshownveh; 
int near[ MAXVEH]; 

DRAWVEHPOSTYPE listfMAXVEH]; 
int vehnof MAXVEH]; 



}; 

/♦what terrain to draw*/ 
struct drawdirtbuffertype { 

int minx, maxx, minz, maxz; 
char **drawarray; 

}; 

char waiting; 

/* the buffer structure for the producer-consumer*/ 
struct bufftype { 

usema_t *semaphore; 
char fillflag, waiting; 
struct drawdirtbuffertype terrain; 
struct drawlisttype models; 

}; 



/♦the driven entity*/ 

/♦number of entities in the view triangle*/ 
/♦number of entities outside of the view triangle*/ 
/* what resolution to draw it*/ 

/♦Entity state orientation and position vector*/ 
/♦the entity index*/ 



/♦the size of the bounding box for the view triangle*/ 

1 * 2 D array flags used to determine resolution and LoD*/ 



/♦the semaphore for this buffer*/ 

/* True / False if the buffer is filled / or being waited on*/ 
/♦the array of grid squares to draw*/ 

/* the array of entities to render */ 



Figure 43. Display Buffer Data Structure 
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the X and Z directions. If the resolution value is non zero, the resolution and the XZ coordinates are used as 
an index into the quadtree data structure to render the polygons associated with that grid square. Once the 
polygon list is retrieved, the polygons are then rendered. When all of the terrain skin has been rendered the 
objects are then drawn. The “terrain.drawarray” is once again traversed to determine what resolutions are to 
be used for each of the selected grid squares. The resolution value serves as an index into the object’s eleva- 
tion array to ensure the object is planted on the ground. (See Chapter V for a more in-depth discussion of el- 
evation determination.) For each of the selected grid squares, the objects are rendered at the selected elevation 
and LoD. 
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Figure 45. The Four Phases of Rendering Traversals 



The third pass of the display buffer by the rendering process is done to render the entities. The 
“models.list” array contains two stacks. The first stack’s base is at “models.list[ 1]” and it’s head is at “mod- 
els, vehcount”. This stack contains the entities that are in the field of view. A for loop is used to render all of 
the entities on the stack based upon the positions, orientations and types of the entity specified. The level of 
detail for the particular entity is contained in “models, near” array. The second stack grows down to “ model - 
s.notshownveh” from “models.listfMAXVEH -1 j.” The locations of the models in the second stack are used 
only by the 2D map to show where the entities are currently located in conjunction with the “ model s.vebno” 
array. “models.listfO]” is a special location containing the description of the currently driven entity. 
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The fourth pass of the database is done to render the currently active missiles and explosions. The 
same techniques as the entity rendering are used to select the missiles. The difference is that a single stack of 
missiles, only those in the field of view, is used. The explosion array is used to position the texture maps of 
the blast in the world. Since the texture maps that simulate explosions have an alpha component, they must 
be drawn last or there might be interference with the Z-buffer values. Since the explosions are rendered as a 
textured polygons, the algorithm in Figure 46 is used to ensure the polygon is perpendicular to the eye point. 
This same technique can be applied to trees and other symmetrical objects. By using rotating billboards for 
this category of objects, we can dramatically reduce the polygon count on the database in exchange for a few 
more computational cycles. 



/♦Compute the amount to rotate the billboard, 90 degrees from the line of sight*/ 
if ((explode_pos[X] - Entity_pos[X]) = 0.0) { /*When Delta X = 0, fatan2 infinity and gags*/ 
rotamount = 0.0; /*0 Radians*/ 

} 

else{ 

/♦Find the arctangent of delta Z over delta X*/ 

rotamount = fatan2((explode_pos[X] - Entity_pos[X]), (explode_pos[Z] - Entity_jx>s[Z]»; 

} 

/♦Draw the billboard*/ 
pushmalrixO; 

/♦Translate to the origin of the billboard */ 
translate(explode_pos[X], explode_pos[Y], explode_pos[Z]); 

/♦Rotate so it is at 90 degrees from the line of sight */ 
rot(rotamount/DEGTORAD, ’Y‘); 

/♦Draw the flat Explosion*/ 
popmalrixO; 

> 



Figure 46. Algorithm for Rotating Billboards 



The remaining functions of the renderer are to draw the 2D map and the information panel. The 
2D map uses the “models. list” and “ models .vehno” arrays to specify where the entities are and what their en- 
tity number is. It also uses the elevation posts from the terrain to generate an elevation shaded display. The 
values for the information panel are derived from “models. list[0]” and system parameters. 



6. Network Management 

As stated above, the function of the network management routines is to control the flow of PDUs 
on to and off of the network. The network management routines are actually made up of two components, the 
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send interface and receive process 5 . Figure 34. The send interface acts as a formatter and is called directly 
from the application. Once the data is formatted, a system call is made and the data is turned over to the op- 
erating system’s network demon for actual placement on the wire. Since the application can control when it 
has data to send, this is part of the application process. 

The receive process is made up of two components. When a PDU is received from the network 
demon, the read process reads the message into a buffer and holds it there. The application’s network read 
routine then reads it from the buffer in the appropriate place in the simulation loop. At this time, the data is 
formatted into the internal formats and processed by the application. This formatting and processing might 
amount to nothing more than discarding the message if the application does not support the function specified 
in the PDU. The implementation of the network interface and PDU formats are covered in more detail in 
Chapter X. 

C. DATA FLOW AND SEQUENCING 

So far this chapter has generally dealt with the functional requirements of the software components. For 
the most part, these components have been dealt with in isolation. The remaining portion of this chapter cov- 
ers the interconnection of the components both in terms of data, data flow, and in time sequencing. 

1. Inter proccess Data Flow 

As shown in the section on rendering above, the processes need to communicate with each other 
to achieve their desired functions. The display buffer is one example of the data flow from one process to 
another. In Figure 47, a simplified data flow diagram shows some of the data that has to be passed from pro- 
cess to process. Purposely not shown in Figure 47 or discussed in this section, are the global data stores, such 
as the global flags and terrain database, that are available to all of the processes. The data that is generated or 
transformed in one process and then passed to another is the focus of this section. 

As shown in Figure 44, the rendering process receives a filled display buffer from the scene man- 
agement process. As stated above, this contains the information needed to render the scene in an efficient 
manner. It also contains a flag indicating that the buffer is full and that the rendering process can use the data. 

5. For the purpose of the Network process, we define an interface as a piece of code that is called by 
a function to convert some data. It retains the callers thread of execution and returns to the caller 
upon completion. A process is spawned and maintains it own thread of execution and communi- 
cates to the caller by means of shared memory. In the final version of the network harness, the put- 
ting of messages on the network was implemented as an interface and the getting of messages was 
implemented as a process. 
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Next Buffer 

Figure 47. Primary Interproccess Data Flows 



The data flow out of the Tenderer is a single variable indicating that the buffer has been emptied. As discussed 
in "Process Sequencing and Synchronization", this serves as an indication that the computing of the next 
frame can begin. 

In addition to the frame commence flag from the Tenderer, the input process receives data from 
the user via the system’s input queue. In the case of N PS NET- 1 +, the Ascension Bird is also polled as an input 
data flow. This data is then correlated and transformed into internal formats before it is passed on to the dy- 
namics process. 

The dynamics process combines the data from the input process, the messages that have been buff- 
ered by the network manager to form the input, and the current state of entities to develop the current state of 
the world. In addition to the input flows mentioned above, the latest version of the NPS Stealth has been mod- 
ified to accommodate a socket based connection from a true dynamics based simulation of the Unmanned Air 
Vehicle (UAV). In the NPSStealth version, the dynamics and control of the UAV are computed on a separate 
computer and the results are fed to the systems’s dynamic process over the Ethernet using point to point sock- 
et communications. The output of the dynamics process is the location, orientation, and status of the driven 
entity and all other players in the world. Part of the dynamics process manages the temporal events 6 , so the 
results of these are also output. As shown in Figure 47, the data flows out of the dynamics process, going to 
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both the network management process and to the scene management process. Certain events, such as the 
change in velocity of driven entity or the firing of a weapon system, that originate in the local host and need 
to be communicated to others hosts, make up the data passed to the network manager. The scene management 
process is sent the eye point data necessary to efficiently perform its given task. 

As shown in Figure 47 and discussed above, the scene management process receives the eye point 
information from the dynamics routine. It then uses this data, combined with the global flags and the player 
and terrain databases, to generate the display buffers. The display buffer is then passed to the rendering pro- 
cess completing the actions required to render a frame. 

The network process, when active, receives information from the dynamics process. It then for- 
mats the data into PDUs and manages the placement of them on the physical network. The outputs from the 
dynamics process are the buffered PDUs read off of the network. This data flow is provided as an input to the 
dynamics process. 

In this section, we have discussed the major data flows. Some of the smaller flows, such as the 
data passed between the input process and the renderer to manage the menus or between the input process and 
the network management process to enable / disable the network, are important from the control and manage- 
ment point of view, but are outside the normal data flow. 

2. Process Sequencing and Synchronization 

In the way we use them, sequencing and synchronization have a subtle but important difference. 
Process sequencing is ensuring that the processes run in the correct order, for example the renderer always 
runs after the scene management process. Process synchronization is making sure that the process runs at the 
correct time with the correct data. An example of this is that display buffer A is rendered before display buffer 
B is rendered. Single threaded processes have built in sequencing and synchronization, the thread of execu- 
tion steps from one portion of the code to the next. Parallel processes have multiple threads that must be se- 
quenced and synchronized, normally by some external means. During the initial stages of the discussion, we 
assume that we do not have any machine imposed Limitations. This represents the ideal case. After the pre- 
sentation of the ideal case, the real world implementation of NPSNET on an SGI platform is covered. 

The idealized case is presented in Figure 34. Notice how the logical process we have discussed 
has been parallelized across different processors and interwoven with each other. The prime example of this, 

6. A temporal event is a discrete event that happens at some particular time that affects the state of 
the world. An example of this is a missile being fired. The flash of the launch is a temporal event 
The same applies to muzzle flashes, explosions, and collisions. 
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is the distribution of the dynamics process across the different processors to accommodate the driven entity 
and the other players. This process is interwoven with the scene management process. As a player is moved, 
a check is done to determine if it is in the view volume. If so it is added to the display buffer and rendered. 
While that one player is being rendered, the next is being moved. As shown in Figure 34, the critical path 
starts at the input process, goes though the dynamics process of the driven entity, then the construction of the 
view volume, and ends at the renderer. The reason for this is simple. The controls have to be read to determine 
how the dynamics are going to affect the driven entity. Once the location and orientation of the driven entity 
are determined, the eye point can then be used to construct the view volume. The view volume in turn deter- 
mines which of the other player’s icons is passed to the renderer. The renderer is itself distributed across dif- 
ferent processes, the terrain is being rendered while the various players are also being drawn. The primary 
synchronization is the determination of when a frame is complete, and when a new view volume has been 
computed and which display buffer to write into. Both sequencing and synchronization are accomplished by 
means of semaphores. Semaphores are also used to enforce mutual exclusion to the PDU input buffer, to make 
sure we are not reading and writing at the same time. 

As mentioned above, that is how an ideal system works. In our implementation of NPSNET, we 
found some limitations of the hardware that we had to deal with. Foremost among these was that only one 
process can write to a window at a time, the graphics pipeline is a not a shareable resource among the separate 
threads. This requires the locking of the pipe from all other processes when graphics primitives are being 
passed from a process to the renderer.This results in locking and unlocking the graphics pipeline to do any- 
thing that is displayed on the screen, such as pop-up menus, which are controlled by the user input process. 
In addition to the time required to lock the pipe, the amount of time required to reload the graphics context is 
quite high. Even with aggressive scene management, NPSNET is extremely graphics bound. A further limi- 
tation was that all of our machines have a finite number of processors, and context switching does take some 
overhead. Knowing these three data points, we decided not to develop the system architecture shown in Fig- 
ure 34. The resulting structure has three active processes, in addition to the terrain management process dis- 
cussed in Chapter V. The main process combines the input, dynamics, scene management, and network PDU 
writing processes into a single thread. The rendering thread receives the filled display buffer from the main 
process and passes to the hardware graphics pipeline. The network thread buffers the incoming PDUs to be 
read by the main process. 

While this architecture only uses three threads, it has proven to be quite efficient. We have done 
empirical studies on this architecture on a SGI 120/GTX, 240/VGX, and 320/VGX, and the rendering process 
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is the bottleneck. To ensure correct timings, the rendering process was locked to the second CPU. On the two 
CPU models, the UNIX demons, network read process, and the main process all ran on the first CPU. The 
four CPU model has the network on CPU four and CPU three processed the main thread. For all of these tests, 
the limiting factor was the rendering process. We were able to double the number of players to 500, and im- 
plement real time collision detection without affecting the frame rate. Naturally, when more entities are with- 
in the field of view, the system slows down due to the rendering bottleneck. 

The system’s main input / compute / draw loop architecture is basically a producer - consumer 
configuration with a buffer size of two. The two buffers are labeled Buffer 0 and Buffer 1 in Figure 44. The 
main loop fills one buffer while the Tenderer is drawing from the other. The synchronization points are when 
each of the threads are done with their respective buffer and must mark it as available for the other process. 
As shown in the code fragments in Figure 48 and Figure 49, semaphores are used to guarantee mutual exclu- 
sion to the fill and waiting flags. We chose spin wait semaphores for the buffer rather then block semaphores, 
since each of the processes have their own CPUs. In such a case, one spin waiting does not affect processing 
of the other process. The coding was also simpler, and we could avoid the overhead of blocking / unblocking 
a process. 

For both the ideal and actual architectures, the network process functions basically in the same 
manner. The incoming PDUs are buffered asynchronously from the network. The last step of the input pro- 
cess reads the PDU queue. Semaphores are used to enforce mutual exclusion in order to prevent the corruption 
of the incoming PDU queue. 

D. SUMMARY 

In this chapter, we have developed and justified a basic software architecture for a real time VW. While 
many of the design decisions we took were geared towards the implementation of NPSNET on an SGI work- 
station, the fundamental architecture can be applied to all VW systems. 
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/* This code fragment is used by the scene management process to fill the 
buffer*/ 

/*swap the active buffer, “fbuff" stands for filling buffer*/ 
fbuff = (fbuff + 1) % 2; 

/♦semaphore block wait for the buffer to empty*/ 

/*get exclusive access to the fill flag and waiting variables*/ 
ussetlock(bufflockf fbuff]); 

i f(displayb uffer[ fbu f f] . fill flag) { 

/*the buffer is full, so wait until it is empty*/ 
displaybufferf fbuff). waiting = TRUE; /*mark it as waiting*/ 
/*if we don’t give up the lock, we will cause deadlock*/ 
usunsetlock(bufflock[fbuff)); 

/♦decrement the semaphore and wait*/ 
uspsema(displaybufferf fbuff]. semaphore); 

} 

else{ 

/♦the buffer is empty, start to fill it*/ 
usunsetlock(bufflock[ fbuff]); /*give up the lock*/ 

} 



/♦Buffer Fill routines go here*/ 



/♦Allow the drawing of this buffer*/ 

/♦get access to the variables*/ 
ussetlock(bufflock[ fbuff]); 

/♦mark the buffer as full*/ 
displaybuffer[ fbuff]. fillflag = TRUE; 

if (displaybufferf fbuff) .waiting)} 

/♦the graphics process is waiting on this*/ 
displaybufferf fbuff]. waiting = FALSE; 
usunsetlock(bufflock[ fbuff]); 

/♦increase the semaphore to allow the drawing process 
to unblock*/ 

usvsema(displaybuffer[ fbuff]. semaphore); 

} 

elsc{ 

/♦nobody was waiting on it so just keep going*/ 
usunsetlock(bufflock( fbuff]); 

} 



Figure 48. Semaphore Synchronization of Filling Buffers 
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/* This code fragment is used by the render process to fill the buffer*/ 

/♦swap the active buffer, “dbufr stands for drawing buffer*/ 
dbuff = (dbuff + 1) % 2; 

/♦Get access to variables*/ 
ussetlock(bufflock|dbuff|); 

i f( ! di splay bu f fer[ dbu f f] . fi 11 flag) { 

/♦The desired buffer is empty*/ 

/♦wait until that buffer is available */ 
displaybufferf dbuff] .waiting = TRUE; 
usunsetlock(bufflock[ dbuff]); 

/♦decrement and wait*/ 
uspsema(displaybuffer[ dbuff]. semaphore); 

} 

else{ 

/♦buffer is full, draw it*/ 
usunsetlock(bufflock[dbuff]); 

} 



/♦The drawing routines go here*/ 



/♦free up the buffer and mark it as empty*/ 
ussctlock(bufflock[dbuff]); 
displaybufferf dbuff]. fill flag = FALSE; 
if( display buffer! dbuff]. waiting) { 

/* the Fill process is waiting for the buffer*/ 
displaybuffer[dbuff].waiting = FALSE; 
usunsetlock(bufflock[dbuff|); 

/♦increment and allow the fill process to proceed*/ 
us vsema(display bu ffer[ dbu f f] .semaphore) ; 

} 

elsc{ 

/♦nobody is waiting*/ 
usunsetlock(bufflock[dbuff|); 

1 



Figure 49. Semaphore Synchronization of Drawing Buffers 
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VII. ENTITY DYNAMICS 



Dynamics is the study of relationships between the forces on and the resulting motion of entities. There 
are many different aspects in the construction of systems based on dynamics. Some systems, such as SIM- 
NET, have extremely accurate dynamics to simulate the actions of the real world [GARV88]. Other systems, 
such as most of the VPL systems, have very little real world dynamics [BLAN90]. For NPSNET, we devel- 
oped and implemented a set of simple, yet realistic, dynamics models that run in real-time. The entities in 
NPSNET move in a manner consistent with what the user would expect to see in the real world. Since no one 
dynamics model works for all types of entities, we divided the entity types into groups based upon the envi- 
ronment that they operate in. Thus the sea, land, and air entities each have a different dynamics model. 

In this chapter, we present a brief overview of the mechanisms used to control and maneuver the enti- 
ties. This is followed by a discussion of the dynamics models used to describe the motion of the entities in 
the VW. The chapter concludes with a detailed discussion of the mechanism used to detect collisions between 
entities and objects. 

A. ENTITY CONTROL 

In NPSNET there are two types of controlling mechanisms. They are based on the dynamics model used 
to control the entity, the user controls the forces which act upon the entity. For the air entities, the user uses 
the SpaceBall, a six degree of freedom joystick input device, to mimic the stick and keys to control the engine 
thrust, aircraft trim, and rudder. The force values associated with the control surfaces and engine are part of 
the aircraft dynamics model. For the land entities that use a dynamics model, the SpaceBall and key combi- 
nations are used to control the forces directly. 

The motion of entities which do not have a specific dynamics model, ships and some land vehicles, is 
determined using first order positional and zero order orientation control. Table 5 shows the different control 
orders and their effects. For example, the first order control of position used in NPSNET requires the user to 
provide an input to change the speed of the controlling entity. If the user does not touch any of the input de- 
vices, the entity continues at the same speed until it collides with something or it runs out of fuel. Likewise 
the zero order control over orientation dictates which direction the entity is heading. For land and sea entities, 
this is a two dimensional heading since the pitch and roll must conform to the polygonal skin. Since air entities 
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do not have that restriction, the pitch and yaw are controlled by the user and motion is permitted in three di- 



mensions. 

Table 5: LEVELS OF CONTROL FOR NON-DYNAMICS CONTROLLED ENTITIES 



Control Level 


Position 


Orientation 


Zero 


Position 


Orientation 


First 


Speed 


Turn Rate 


Second 


Acceleration 


Angular 

Acceleration 



B. ENTITY MOTION 

As discussed above, the routines which describe entity movement have been divided into three basic 
categories according to the normal operating environment of the entity. In this section, we discuss some of 
the salient algorithms and implementation issues involved in each one. 

1. Sea Entities 

The modeling of sea entities is the simplest of the three types for two fundamental reasons. At the 
time of this writing, a model based on true dynamics of sea entities has not been completed. In addition, the 
ocean in NPSNET is flat, and as a result, the pitch, roll, and elevation of a sea entity are all trivially zero. The 
state vector of the sea entity is made up of its speed and heading. As shown in Figure 50, these parameters 
are sufficient to determine the location of the entity. The speed and heading of ships are modified directly by 
SpaceBaLl inputs. This often results in very unrealistic ship movement, particularly in the turning of the ships. 
Other students and faculty at NPS are currently involved in implementing ship dynamics for NPSNET. 

2. Land Entities 

As mentioned in the introduction, the focus of NPSNET is on land combat. Thus, the majority of 
work has been in the modeling of land entities. In this section we present the models used to control the be- 
havior of both the non-dynamics based and dynamics based land entities. 

a. Non-Dynamics Based Entities 

Non-dynamics based land entities share the same basic control algorithm as the sea entities 
above. However, there are a few significant differences. The first of these is in the computation of pitch and 
roll, which is discussed in "ICON PLACEMENT ON THE TERRAIN" and shown in Figure 25. Initially, the 
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normal of the polygon was used to determine the pitch and roll of the entity on the terrain. While this method 
works well when the entity is completely on a single polygon. Figure 51 shows the result when the entity 
crosses polygon boundaries. This instantaneous change of orientation is unrealistic and visually disconcert- 
ing. To correct this, we decided to use the projected point method 1 . As shown in Figure 52, the projection of 
the point along the positive X axis is used determine the pitch of the entity. This is used to realistically model 
the cresting of a ridge or traversing a valley. Care must be taken to position the projected point at the front of 
the entity’s bounding box. If it is too far out, the entity starts to crest the ridge before it has gotten to it. Like- 
wise, if the point is too close to the center of the entity, the nose digs into the opposite side of the valley. The 
same methodology, with the point projected out to the side, is applied to determine the roll of the entity. While 
this is not an accurate model of the entity’s suspension system, the visual results are quite good. 

The second major difference between the sea and land entity movement routines, relates to 
the size of the icons. The land entities are at least one and sometimes two orders of magnitudes smaller than 
the sea entities. This allows them to be considerably more maneuverable, and thus, the direct control of the 
heading is not as disconcerting as it was for sea entities. 

1 . A version of this method was presented in [SMIT87]. We have drastically modified the algorithm 
to use it in NPSNET. 
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Entity is completely on a single 
polygon. Pitch and roll is equal to 
the polygon’s normal. 



Entity is cresting a ridge, but 
the center is still on the upward 
polygon. 



The entity’s center has just crossed 
the polygon boundary and the pitch 
and roll changed to conform to the 
downward polygon. 



© Entity Center Point 

Figure 51. Use of Polygon Normal to Determine Pitch and Roll 



Entity is completely on a 
single polygon. Both the 
center and projected points 
are on the same polygon. The 
entity’s pitch is equal to that 
of the polygons. 



As the entity crests the hill, the 
projected point moves over to 
the next polygon. The pitch is 
now between the upward and 
downward sloping polygons. 



The center point has moved 
onto the downward sloping 
polygon. The pitch of the 
entity and the polygon are 
now the same. 

• Front Projected Point 

Figure 52. Use of Projected Point to Determine Pitch and Roll 
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b . Dynamics Based Entities 2 

The dynamics based land entities are grouped into two classes depending on their suspension 
mechanism: wheeled entities and tracked entities. The two movement routines for the classes, differ in how 
propulsive forces are applied, but they both share some common dynamics properties. Among these is the use 
of “close enough” friction to approximate the effect of real friction [WILH88]. Correctly modeling the effects 
of friction is a complex process, which is further complicated by trying to incorporate different soil types and 
plane orientations and include the effects of gravity. To simplify the process, we assign each soil type a stick 
angle and a resistive force. The stick angle is the angle of the polygon at which the entity starts to slide. The 
resistive force is the amount of force opposing the motion of an entity and is tangent to the surface of the poly- 
gon. The resistive force is based upon the soil type and is independent of the orientation of the polygon. The 
force of gravity is combined with the resistive force to produce the moving frictional force. Since gravity pulls 
downward, the total frictional force is less when the entity is going down hill than when it is going up hill. 
Thus, as in the real world, entities subject to a constant force decelerate going up hill, accelerate going down 
hill, and maintain a constant velocity on level ground. When no force is being applied to an entity, the friction 
forces causes it to slow down and eventually stop. 

The first category of dynamics based land entities are the tracked entities. These are entities 
such as tanks, bulldozers, self-propelled artillery, and armored personnel carriers. As shown in Figure 53 , we 
modeled this class of entities with two propulsive forces. Each of these forces represents one of the entity’s 
tracks and is parallel to the central axis of the entity. The forces are offset from the center of mass allowing a 
torque to be applied to the entity. When the two forces are equal, the torques cancel out and the entity moves 
in a straight line. If the forces are unequal, the entity turns to the side of the weaker force. To rotate the entity 
around its Y axis, equal and opposite forces are applied as shown in the figure. The forces model the actual 
track speeds of the real vehicles. 

Wheeled entities are the other major class of land entities. This class is modeled with a fixed 
rear axle and a steerable front axle, Figure 54. The single propulsive force is applied along the central longi- 
tudinal axis of the entity. When the front wheels are straight, the entity moves straight ahead. However, when 
the user turns the front wheels, the entity turns at angle 0 per unit time, as a function of the co mman ded steer- 

2. Hyun Park’s Master’s Thesis, [PARK92], contains more details of the implementation of the 
wheeled and tracked dynamics model. In [WA1T92], Alan Walters extends Park’s work to include 
the effects of soil type and slope. As two of my students, many of the ideas were developed jointly 
during our discussions. Detailed derivations of the dynamics equations can be found in their 
respective theses. 
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Resulting Motion 





Figure 53. Forces Applied to Tracked Vehicle 

ing angle a , the length parameter of the entity d , and the turning radius p . The turning radius can be derived 
from the length of the entity and the commanded steering angle using the following equation: 

p = J((2d) / (tana ) ) 2 + d 2 

The simplified dynamics models discussed here for land entities are realistic enough to en- 
sure acceptable behavior and simple enough to be run in real-time. 

3, Air Entities 3 

The land based entity models discussed above, allow only two and a half dimensional motion be- 
cause the entities are bound to the polygon skin representing the terrain and cannot roll over or pitch up. The 
airborne entities, on the other hand, are free to move in all three dimensions. This presents a more complex 
problem. One important issue is what happens when the entity goes though a ninety degree (vertical) pitch 
maneuver. Physically, the heading instantly switches by 1 80° and the world appears to be upside down. When 
this happens to a vertical gyroscope a real physical phenomenon known as gimbal lock occurs. In a simula- 



3. The aircraft dynamics model was developed by one of my students, Joseph Cooke, and is pre- 
sented in detail in his diesis, [COOK92]. The model is presented here for completeness since it is 
an integral component of NPSNET. 
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tion, a similar problem exists because the Euler angle rates are unbounded at ninety degrees. To eliminate the 
problem in simulation, one solution is to never allow an air entity to go through 90° , but instead to make a 
discontinuous maneuver to avoid this singularity (i.e. hard-coding a jump between 89.99° to 90.01 ° ). In ad- 
dition to this problem, the computation of Euler angles is computationally expensive involving transcendental 
functions. To avoid this cost a new way of determining the position of the air entity was used. Quaternions 
are a means of describing an orientation in three dimensional space. The quaternion vector is a four compo- 
nent vector. Figure 55. The first three components of the vector are the vector representing the unit orientation 
vector, The remaining scalar represents the rotation around the axis, <I>. The quaternion orientation model 
can be computed directly from the dynamics model. However, display and network standards require the con- 
version of the quaternion vector into Euler angles, so the entire benefit of quaternions is not realized in the 
current version of NPSNET. 

A complete aerodynamics model is used to describe the motion of the aircraft through three di- 
mensional space. The model takes into account all of the control surface deflection of a normal aircraft and 
such factors as engine spool-up characteristics. Specific aircraft data, such as engine thrust, maximum control 
surface deflection, weight, lift coefficients, etc., are stored in an ASCII file which is read as part of the ini- 
tialization of the Start-up process. This data is then used to determine the coefficients for the dynamics equa- 
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tions. This allowed us to implement a single model that could realistically simulate the characteristics of a 
wide range of aircraft simply by changing the parameters of an ASCII file. 



C. COLLISION DETECTION AND RESPONSE 4 

In the real world, all objects experience contact detection and response, and it is important to model this 
behavior in the VW as well, because it is unnatural for things to be interpenetrated without incurring any dam- 
age. Seeing such events occur destroys the sense of the reality that we are trying to create. The drawback to 
meeting this requirement is the large computational load involved in adequately determining the contact lo- 
cation. 

The simplest form of contact is one object sitting on top of another object There is contact along the 
common boundary. In most cases, the response to this contact is static support of the object on top by the 
object below. A collision is a special case of contact involving the instantaneous contact of two or more en- 
tities. This instantaneous action indicates that at least one of the objects has a velocity associated with it. A 
simple example of the difference between the two is as follows: Contact is when one leans statically against 



4. This section is based largely on William Osborne’s Master Thesis, [0SB091]. This work was 
done under my supervision and represents an implementation of my ideas. 
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a wall; collision occurs when one walks into the wall. Since the only form of contact detection in NPSNET 
is the motion of entities over the polygon skin and the placement of objects on the terrain, both discussed in 
the proceeding sections, "ICON PLACEMENT ON THE TERRAIN", "Land Entities", and "Sea Entities", 
we do not discuss them further here. Instead, we focus on the collision detection required by moving entities. 
Once a collision has been detected, the system has to enter a resolution phase. In the case of someone walking 
into a wall, the cessation of forward motion and a quick glance around to make sure no one saw what just 
happened are typical responses. If a faster speed was involved, there might be some form of injury as well. 
This little example brings up a very interesting point. Collision response involves both physical and behav- 
ioral components. In this case, the change in motion and injury were physical responses, while the looking 
around was the behavioral response. It is both these types of responses we are trying to capture in the collision 
detection and response. 

Since we are limiting our discussion to moving entities, we have subdivided the problem into two areas, 
both of which are discussed in detail below. The first case deals with a moving entity and a static entity. The 
second case involves two moving entities. This division is based upon the different requirement for detection 
and response in each of the cases. 

1. Moving / Static Collision 

The simpler of the two cases of collisions is the case involving moving objects and static objects. 
An example of this case is a tank running into a tree. If we were to use a brute force method of checking every 
object against each other, in every frame we would have to determine if the tank collided against all possible 
trees. In the case of the Fort Hunter-Liggett database, this amounts to over 31,000 objects. Table 3. When we 
consider that this check has to be done for each of the 500 moving entities in the world, this amounts to over 
15,500,000 collision detection operations per frame, or 232,500,000 per second at 15Hz. Assuming that each 
test took only ten operations (a simple two dimensional distance check takes about this many mathematical 
operations) we require a 2,325,000,000 Flop machine just to do the contact detection in real-time. Clearly, 
the brute force approach is not the most efficient way to do this. 

Rather than using brute force, we exploit three of the key aspects of the NPSNET world: the world 
is segmented into grid squares, the objects and entities are smaller than the grid squares, and entities move a 
relatively small distance in each frame. The segmentation of the world is discussed at length in Chapter V. 
The relatively small size of all the objects and entities means that they do not extend more than one grid square 
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along any axis. As shown in Table 1 , each of the entities travel a small distance, less than one gnd square per 
frame. 

Exploiting these three facts, we can limit the area of concern to a three by three set of grid squares, 
Figure 56. The adjoining grid squares must be included to test objects that extend over the grid square bound- 
ary or when the entity crosses over the boundary. From the figure and Table 3 , we can see that, on the average, 
we only have to do collision detection against less than two objects for each entity per frame. When there are 
a large number of objects in each grid square, the area of concern can be further reduced by divided the loca- 
tion of the entity in the central grid square into one of four bins. As shown in Figure 57, each of the bins needs 
to checked against the three neighboring grid squares. Due to the sparseness of our sample databases, this 
enhancement was not added into N PS NET. The three by three array is chosen by selecting the center grid 
square as the current location of the entity. 
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Figure 56. Area of Concern for Collisions 



The first level collision detection is based upon the entity’s height above the terrain. Since all of 
the objects are attached to the polygon skin, if an entity is above the tallest object in the grid square, there is 
no chance for a collision to occur. If it is below the maximum height, then the collision detection algorithm 
proceeds to the next level. 
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In the second level of contact detection, the two dimensional distances between all of the objects 
and the entity are computed. Stored with each of the objects is a bounding cylinder, Figure 58. We chose a 
cylinder rather than a sphere, since it was a closer approximation of the shape of the object. Specifically, the 
trees are fifteen meters tall, but only five meters wide. The use of a bounding sphere would yield many erro- 
neous collisions. If the two dimensional distance is less than the sum of the object’s and entity’s radii, a third 
level check is done. The final check ensures that the entity above ground elevation is less than height of the 
object. If the entity passes all of these test, a collision has occurred. 

Once a collision has been detected, the system enters into a resolution phase. In the interest of 
speed, we have chosen to use a table driven response system similar to [HAHN88]. Shown in Table 6 is a 
small extract of the system collision resolution table. The basic rules are quite simple; the faster the entity is 
traveling the more damage is caused, the more mass in the object, the more damage to the entity, weapons 
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always cause maximum damage due to their explosive nature. This simple table driven approach produced 



very good results with a minimal additional computational load. 



Table 6: ENTITY / OBJECT COLLISION RESOLUTION BY ENTITY SPEEd 





Tree 


House 


Rock 


Tank 


Stop/None 8 


Stop/None 


Stop/None 




Destroyed/Knocked Over 


Destroyed/None 


Destroyed/None 




Destroyed/S tump 


Destroyed/Ruins 


Destroyed/None 


Airplane 


Destroyed/None 


Destroyed/None 


Stop/None 




Destroyed/Knocked Over 


Destroyed/None 


Destroyed/None 




Destroyed/Stump 


Destroyed/Ruins 


Destroyed/None 


Missile 


Destroyed/Destroyed 


Destroyed/Destroyed 


Destroyed/None 




Destro yed/Destroy ed 


Destroyed/Destroyed 


Destroyed/None 




Destroyed/Destroyed 


Destroyed/Destroyed 


Destroyed/None 



a. Each of the three lines are formatted as Entity Result / Object Result. The lines are based upon 
the entities speed, with slow, medium, and fast from top to bottom. 



As mentioned previously, two of the important characteristics of NPSNET are the use of slow en- 
tities and small objects relative to the grid size of the database. If either of these facts are not true, the meth- 
odology presented here does not work in its entirety. To compensate for larger objects, the size of the area 
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that has to be checked has to be expanded from three by three to five by five grid squares or laiger. When the 
size of the objects are small compared to the area of concern, the same types of checks can be performed. 
When the speeds of the entities are significantly larger than the size of the entity, the radius check can skip 
objects along the path. To compensate for this, we use a volume that is swept out by the path of the entity 
from its last position to the current positions, Figure 59. This is first level collision detection test used for the 
missiles in NPSNET. 
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Figure 59. Fast Moving Entity Collision Volume 





2. Moving / Moving Collision 

If an entity has not collided with an object, it is then checked to see if it has hit any of the other 
entities. To improve efficiency, we have divided the collision detection algorithm down into three levels. 
Each of the levels is increasingly more complex and accurate. The first level is checking to see if any other 
entity is within one hundred meters along the X or Z axis. As shown in Figure 60, the first rough cut serves 
the same function as the grid based selection of the objects presented above. If an entity passes the first level 
check, the bounding spheres and the three dimensional distance between the entities are used to determine if 
contact has actually occurred, Figure 61. The bounding spheres used are not true bounding spheres, but rather 
spheres in which the radius equals the maximum distance along any axis from the origin of the icon. This 
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results in a slightly smaller sphere that might exclude the comers of the object. This increases the chance that 
any collision reported is actually a true collision. 



^Entity Not Considered Further 




Entity Passes 
First Level Check 






/ 100m From Entity 








^Location of Entity 


Figure 60. First Level Distance Based Collision Check 



The first two levels of the collision detection are used to determine if a collision has occurred, but 
does not give any indication where the collision occurred. To identify the location of the collision, we use a 
modified version of ray tracing from (GLAS89]. Normally, ray tracing is a computationally expensive pro- 
cess which is not run in real-time. However, we are using only a single ray and icons with a low polygon count 
(normally less than 200 polygons per icon). As a result, the additional computational load is not too signifi- 
cant if we apply the ray tracing technique judiciously. Hence, it is the final check. A ray is cast from the origin 
of one of the entities to the origin of the other, Figure 62. This ray passes through the collision point and the 
polygons that have interpenetrated the other entity. From these intersections, we can determine where, in 
body and world coordinates, the collision has occurred. If the summation of the distances from the origin to 
the polygon intersection is less than the distance between the entities, then no collision has occurred, Figure 
63. 

Once the collision point has been determined, collision resolution must be performed. Presented 
algorithmically in Figure 64 and graphically in Figure 65, the response is based upon the angle and speed of 
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Spheres Only Overlap 
(Erroneous Detection) 



Spheres and Entities Overlap 
(Valid Detection) 



Figure 61. Collision Detection Using Bounding Spheres 



Possible Intersected 




Figure 62. Ray Casting to Determine Collision Point For Entity A 
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|Ac, Ap| + |Bp, Bc| < |Ac, Bp| 
No Collision Occurred 




|Ac, Ap| + |Bp, Bc| > |Ac, Bp| 
Collision Occurred 



Figure 63. Ray Intersection Distance Collision Test 



if other entity is a dynamic entity { 

Check for angle of impact; 

If( (angle >=85 &4& <= 95) || 

(angle >= 175 && angle <= 185) || 

(angle <= 5) || (angle >= 355) || 

(angle >= 265 && angle <= 275)){ 

if (speed of colliding vehicle > constant)! 

Kill both Entities; 



/♦Right Side Impact*/ 
/♦Rear Side Impact*/ 
/♦Front Impact*/ 
/♦Left Side Impact */ 

} 



} 

else{/* Not going fast enough to be a catastrophic kill*/ 
Stop both; 

} 

else {/*Glancing collision*/ 

Bounce off each other; 

Diminish speed of both; 

} 



} 



Figure 64. Collision Resolution Algorithm 



94 



impact. Basically, if there is a head-on or side-impact collision at high speed, both entities are killed. At slow- 
er speeds, both entities stop. When the angle is a glancing, the entities bounce off each other with a reduced 
speed and new heading, Figure 66. 




Figure 65. Graphical Representation of Collision Resolution Algorithm 



D. SUMMARY 

The single most interesting thing we found out was the introduction of true dynamics models made the 
entities difficult to control. As humans, we are not trained to think in quantitative forces. Rather we judge the 
amount of force to apply based upon the intermediate results. For example, we do not figure out that it takes 
five newtons to move a box, we continually push harder until the box moves. It is difficult on the VW to de- 
velop the same feel for forces we have in the real world. For this reason, all of the systems have an autopilot 
and all stop features so that when the user controlling the entity becomes hopelessly lost, the system can be 
reset and the user can resume control from a known state. 

While the collision detection we have implemented is admittedly simple, it works quite well. It 
has been very interesting to watch how the tactics of the games have changed. Speeds are slower, there is no 
more hiding inside buildings, and the users are avoiding the areas with a lot of trees. We attribute this to the 
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Figure 66. Glancing Collisions Resolution 



self preservation instinct. If the user is going to die trying to drive their icon in a group of trees, chances are 



he will avoid them. An exception to this is when a user wants to go and “harvest” the trees by shooting them, 
which seems to be one of the more popular pastimes in the NPSNET “Sierra Club Edition.” In the “ A1 Gore” 
version the trees shoot back. 
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VIII. VIRTUAL WORLD POPULATION 



As stated in the definition of VW, one of the key aspects of a VW is the population of the world. By 
population we mean the number of active entities within the world. An active entity is anything in the world 
that is capable of exhibiting a behavior. A human controlled player is definitely an active entity, while the 
tree that gets blown up is in the grey area between being an active and a static entity. A rock that just sits there 
is definitely a static entity. For our purposes, we have divided all of the active entities into four general cate- 
gories based upon the control mechanism. The categories are: reactive behavoir system, scripting system, net- 
work entity and driven entity. Recently, the term “Computer Generated Forces” (CGF) has come to group all 
entities that are under computer control into a single category. In NPSNET, both the reactive behavoir system 
and scripting system controlled entities are part of this category. The controlling mechanisms of the first three 
are the topic of this chapter. The final category, the driven entity control is discussed in Chapter VII. 

A. REACTIVE BEHAVOIR SYSTEMS 

A reactive behavoir system in the context used in NPSNET is a system capable of controlling an entity 
“intelligently.” It is the use of the word intelligently that can create some controversy. For our purposes we 
are defining intelligence as the execution of a basic behavior when a stimulus is applied to an entity. The 
true expert systems, such as the one described in [CULL92], are implemented outside of NPSNET and com- 
municate over the network. As such, these entities are treated as network controlled entities. What NPSNET 
does provide is a limited reactive behavoir system that controls the motion of what can be considered as the 
“noise entities.” These are the entities that are used to populate the world when there are not enough human 
or networked entities to make the scenario interesting. This section discusses the dynamic entities only; the 
response of static entities to stimuli is covered in "Moving / Static Collision". 

The NPSNET noise entity reactive behavoir system has four basic behaviors; zig-zag paths, environ- 
ment limitation, edge of the world response, and fight or flight The behaviors have been grouped by the stim- 
uli that causes the behavior to be triggered. The zig-zag behavior uses an internal timer to initiate the behavior. 
Environment limitation and edge of the world response are both dependent of the location of the entity in the 
database as the source of stimuli. The fight or flight behavior is triggered by external stimuli. The behaviors 
are covered in more detail below. The fifth behavior, collision detection, is handled as part of the dynamics 
process and is covered in the preceding section on "COLLISION DETECTION AND RESPONSE". 
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1. Zig-Zag Paths 



After running many trials with human controlled entities, we noticed when they were shooting, 
they would lead the entity they were shooting at. After a while, these human players got quite good at long 
range gunnery. To make the scenarios more interesting, we decided that the noise entities needed to exhibit 
some sort of evasive maneuvers. Using the standard military doctrine that when an entity is in combat it never 
travels in a straight line for very long, we decided that a zig-zag behavior would be appropriate. The rule set 
is shown graphically in Figure 67, and algorithmically in Figure 68. Basically, sometime between T and 2T, 
depending on the speed of the entity and a random number, the entity makes a turn between zero and forty- 
five degrees left or right The time limitation was imposed to prevent jittering entities and a randomness fac- 
tor. The random direction turns prevent the human users from lining up targets at long distances and as a 
result increases the realism of the scenario. 




2. Environment Limitation 

All entities have a normal operational environment. In the case of a land entity, it is the ground. 
Likewise a ship is expected to operate only on the water. This is a key behavior of the noise entities. While it 
is quite humorous to see a ship go sailing over the mountains, it is not very realistic and destroys any sense 
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if ( 

(entity- > alive) && (! entity- > control) && /*alive and a noise entity*/ 

(current_time > entity->tumtime) && /* on the path long enough*/ 

( entity- > speed >=1.0) && /*moving fast*/ 

( ( 1 flags. networking) l I /*the network is off or */ 

(flags. networking && flags .masterf lag) ) ) { /* this is the master node*/ 

/* generate a turn time based upon the speed*/ 
ix = minimum__of (LENGTHOFTURNTIME, 

(rand() % LENGTHO FTURNT IME - (int) entity- > speed) ) ; 

/♦make sure it stays on track at least one LENGTHOFTURNTIME*/ 
entity- >tumtime = current_time + LENGTHO PTUPNTIME* 2 - ix; 

/♦make it turn*/ 

entity- > direct ion += (float) ( (rand () % 90) -45); 

/♦if the network is active, send out a update message*/ 
if (flags. net working) 

sendupdatemess(current_time, entity) ; 

1 



Figure 68. Algorithmic Representation of Zig-Zag Behavior 



of realism. To avoid this problem, we instituted two simple rules, one for ships and one for ground based en- 
tities, as part of the noise entity behavior. The ship rule is simply that ships have to stay in the zero elevation 
areas. When the elevation of the polygonal skin exceeds zero, the ship turns around. Since we only represent 
ships at sea, this works quite well. A better approach is to check the soil type and ensure that it is of type water. 
This way lakes and rivers could be navigated as well. For ground based entities the opposite holds true. They 
must stay on terrain above zero elevation. These simple rules prevent us from representing tanks in Death 
Valley and ships on the Great Lakes, but are adequate for the noise entities with our current terrain databases. 

3. Edge of the World Response 

NPSNET was designed to run for a long time before it had to be restarted and initially we used a 
small terrain patch. To allow the system to run for extended periods of time, we had to develop a behavior to 
handle the situation of the entities reaching the edge of the world. The only suitable behavior was to have the 
entities turn around and go back from whence they came. As shown in Figure 69, this rule is activated when 
the entity has entered the buffer zone around the edge of the database. The entity then reverses direction and 
heads back into the main part of database. If the entity is initialized at a slow enough speed in the buffer zone, 
it will constantly reverse itself. To avoid this, all entities are checked to make sure they are not initialized in 
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the buffer zone. If they are in the buffer zone, they are moved just outside of it preserving the direction and 
speed. 
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Figure 69. Edge of the World Behavior 



It is interesting to note some of the other ways that the edge of the world was handled in the past. 
One system blew up all the entities when they reached the edge of the world. After awhile the driven entity 
was the only one left alive, provided the user could steer well enough to avoid the edge. Another system put 
the entities in a tight spiral. While it was cute, once again the entities tended to all end up on the edge of the 
world. Another was the system that just flew off in the wild blue yonder. Both of these approaches ended up 
limiting the number of noise entities that were still active after a while. Our personal favorite was one of the 
first versions of N PS NET. A bug allowed us to drive off the terrain and into and over the rest of the program. 
It was a wild ride until the segmentation fault. 

4. Fight or Flight 

Very few real people will sit idly by and allow themselves to be shot. To mimic this, we developed 
the fight or flight behavior. The first phase of the behavior is the receipt of the stimuli, in this case missiles 
that comes close enough to be sensed by, but not to kill, the entity. The “sensor range” is shown in Figure 70. 
A smaller box is within the near miss box, this is the kill box where the missile will kill the entity. Any missile 
within the near miss box will trigger the behavior. If the missile is within the kill box, the entity is tagged as 
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dead. The dead behavior overrides all others. The response to the missile in the kill box varies according to 
the type of entity being modeled. If the entity is unarmed, it turns and aligns its direction of travel with that 
of the missile and heads off at maximum speed. This is the flight response. It assumes that the entity firing is 
located along the reverse azimuth of the missile path and tries to get away from it as fast as it can. The opposite 
end of the spectrum is the fight response used by the entities that are armed. As shown in Figure 70, the entity 
turns forty-five degrees every time it senses a missile. Once it comes within a one turn of the missile's reverse 
azimuth, the noise entity fires a missile along the reverse azimuth towards the original firing entity. These 
simple behaviors have made the scenarios much more interesting and challenging. The user cannot randomly 



shoot at the noise entities with impunity; they shoot back. 




Path of the 
missile 

Case 1 : Entity turns 
in flight of missile 



Path of Entity 




Path of the 
missile 

Case 2: Entity fires back 



Figure 70. Fight Response 



B. SCRIPTING SYSTEM 

Much like a script in a stage play, a script contains a list of instructions that the entity follows during 
the simulation. One of the major uses of scripting systems, known to the SIMNET community as data loggers, 
is the ability to record scenarios and play them back later. The playback ability provides an after action review 
capability that can faithfully reproduce the engagement. This reproducibility is a key factor in the analysis 
process. It allows for all the routes and time sequences to be held constant while varying a single parameter. 
For example, the routes of a squadron of attack aircraft can be scripted to test out different anti-aircraft missile 



101 



engagement ranges. If the aircraft were manned, then there could be subtle differences in timing, routes, and 
pilot mental state that could affect the outcome of the tests. Since the aircraft are scripted, they will fly the 
same route over and over again until the testers, not the pilots, get tired. A similar scenario can be constructed 
for an after action review. During an after action review the evaluators sit down with the trainees and discuss 
the actions taken during the exercise. Rather than relying on the memory of the participants and evaluators, 
the recorded script provides a “ground truth’ 1 of what really happened. Thus, the focus of the review can be 
the “why” of the exercise instead of the “what.” A comprehensive review of scripting systems can be found 
in [WEST91 ]. 

The major drawbacks of scripting systems are their major strength. They are an unchanging recording 
of what has happened. As a result of this, after the introduction of a new event, the rest of the script must be 
invalidated. For example, in the aircraft scenario above, the aircraft might have acted differently if the missile 
was launched from 10,000 meters away versus the 3,500 meters in the script likewise in the after action re- 
view, if a tank had gone left then right, some of the subsequent actions might not have been the same. A pure 
scripting system cannot handle this type of modification. What can be done is to have the script manage the 
entity until some interaction occurs. At that time, the control of the entity is passed off to an expert system. 
The expert system then controls the entity until it can rejoin the scripted actions. 

The scripting of entities in NPSNET is a two phase task. The first phase is the generation of the script 
by automated or manual means. Once the script has been generated, it can then be played back. Both of phases 
are discussed in detail below. Prior to discussing the generation and playback of the scripts, we discuss the 
content of the scripts. 

L Script Content 

The content of the script varies from system to system in terms of both format and content. None- 
theless, there are certain attributes that are shared among all scripting systems. These are the preservation of 
time stamps and entity state information. The time stamp is used to sequence the events in the script and to 
indicate at what time the script data should be applied. The state information contains the dead reckoning pa- 
rameters, component orientation, status information, and location. What constitutes the state information de- 
pends on the system. A single time stamp and state information entry are grouped into a script line. A line of 
the script, much like an actor’s line in a play, is the smallest sequencing action and is treated as an atomic 
unit When a script is written or read, it is done a line at a time. This way the sequencing of the actions are 
preserved. 
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The NPSNET script shown in Figure 7 1 is a fragment of a National Guard Exercise that was held 
in 1988 in the National Training Center, Fort Irwin, CA. For NPSNET, we made the decision that the scripts 
were to be human readable and as such all of the scripts are in ASCII. At first glance, the script is utterly 
meaningless, even in ASCII, but the numbers are actually highly formatted. The first set of three numbers 
is the time stamp for the script line. The entity identifier, entity type, and which side it belongs to comprise 
the required data to select the entity and icon for this script line. The next three are the location of the entity 
in database coordinates. For all non-aircraft, the Y component is 0.0 indicating that the entity follows the 
ground. The next four numbers are used to determining the fire control solution. The last floating point num- 
ber is the speed of the entity. The fire and alive flag complete the script line. These are true / false flags used 
to determine the status of the entity and the appropriate response by the system. 



00 00 11 59 2 8161.926270 0.0 8174.560547 135.989869 0.000000 0.000000 0.000000 12.496254 0 1 

00 00 13 56 2 9659.545898 0.0 5527.709961 178.391381 156.804391 0.000000 0.000000 2.778167 0 1 

00 00 13 107 61 8621.704102 0.0 8938.416016 170.537046 10.795384 0.000000 0.000000 0.000000 0 1 
00 00 13 58 2 7601.989746 0.0 8732.117187 201.021437 118.372680 0.000000 0.000000 0.000000 0 1 

00 00 13 58 2 7601.989746 0.0 8732.117187 0.000000 180.000014 0.000000 0.785398 0.000000 0 0 

00 00 14 124 1 9361.876953 0.0 9833.312500 203.685402 0.000000 0.000000 0.000000 8.330992 0 1 
00 00 15 59 2 8125.976562 0.0 8209.289062 135.989869 168.226653 0.000000 0.000000 0.000000 0 1 

00 00 15 57 2 7855.773926 0.0 8645.324219 162.891606 0.000000 0.000000 0.000000 12.500731 0 0 

00 00 15 60 2 9689.331055 0.0 5599.487305 175.381522 160.417411 0.000000 0.000000 12.507100 1 1 

Format 

Hours Minutes Seconds Entity_Number Entity_Type X_Position Y_Position Z_Position 
Direction View_Direction Gun_Elevation Above_Ground_Level Speed Fire_Flag Alive_Flag 



Figure 71. Typical NPSNET Script 



2. Script Generation 

There are two fundamentally different types of script generation systems. The first is the manual 
method. In this method, the script developer manually enters the data, usually as a series of way points. This 
can be accomplished in several different ways. The two most common are a text entry system and pointing 
device entry. In the text entry system, the developer uses a text editor to enter all of the data. Not only is this 
a time consuming and error prone to type all the numbers in, but the speeds, locations and times must all be 
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computed by hand. The second, more practical, way of generating scripts by hand is to use a pointing device 
to select the way points and a valuator, single degree of freedom, device to select the speed of each segment 
or the time stamp at each way point. Once the path has been laid out, Figure 72, the state parameters and tim- 
ings are computed by the computer, Table 7. The underlined parameters were input by the user, the others 
were computed by the computer. Once the data is generated, it is stored in a file for later playback. The ac- 
curacy of the placement of the entities is limited to the resolution of the input device. This can result is unin- 
tentional co-location of multiple entities. Seeing two tanks merge into a single icon destroys all sense of 
reality built by the system, not to mention collision detection processing. Despite that caveat, using the point- 
ing device is a quick way of generating the scripts and it works relatively well for new scripts [CECI91]. 



Table 7: SCRIPT PARAMETERS GENERATED FROM SELECTED PATH® 



Segment 


Start Position 


End Position 


Speed 


Start Time 


Stop Time 


A-B 


0.0 


100.20 


10.0 


0:00:00 


0:00:10.2 


B-C 


100. 20 


110. 30 


5,0 


0:00:10.2 


0:00:13 


C-D 


1 10. 30 


50, 35 


1.9 


0:00:13 


0:00:45 


D-E 


50, 35 


0, 15 


5X) 


0:00:45 


0:0055.8 



a. Underlined values are input by the user. All other values are computed. 



The second method of script generation is the automated recording of the entity’s actions, known 
as data logging. In this system, every time the state of the entity changes, it is recorded automatically by the 
computer and stored in the script. Once again, there are two basic ways of doing this. The first is the method 
used by NPSNET to generate scripts. In this system, the actions of only the driven entity are recorded. It is 
possible to build a compound script by using the play and record feature which integrates the actions of the 
currently driven entity with the existing script. The second, and perhaps more common, way of automatically 
generating a script, is the use of a recording device that records the states of all of the entities at once. Most 
often this is done by some type of network monitoring device. As packets are placed on the network, the data 
logger reads, time stamps and records them. Since maintaining an accurate state of the world at run time re- 
quires the transfer of the state information across the network anytime it changes (See Chapter X for more 
details about the network component), the PDU stream provides the ideal data and format for the script file. 
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Point D 




Figure 72. Sample Path Layout 

3. Script Playback 

Once the scripts have been generated, the next step is the playback. In this phase, the script is read 
in line by line and applied to the scenario at the appropriate time. The algorithm in Figure 73 shows how this 
is done in NPSNET. As each of the lines are read in, the time stamp in the script is compared to the elapsed 
time in the scenario. If the scenario time is greater, then the line is applied to the appropriate entity. If the 
script time is greater, the function keeps the data in a static area of memory for the next call to the script read 
function. One concession we made to the interactive play of scripted entities is the script reading by dead en- 
tities. If an entity is marked as dead, the script lines for that entity are ignored. This was done after we noticed 
a disconcerting amount of reincarnation going on 1 . Currently this is the only deviation from the prepro- 
grammed script allowed in NPSNET. 

C. NETWORK ENTITY 

A network entity is a special type of entity in that it is transparent to the host what or who is actually 
controlling the entity. The only thing the host needs to know are the dead reckoning parameters to update the 

1. The entities are reincarnated when their next script line is read in from the script file. The script 
line was generated by one the previously mentioned methods. In the original script, the entity did 
not die. 
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read_the_script_f ile ( ) 

{ 

static float next_script_time; /*the time of the next line*/ 

static entity_state script_entity; /*the entity state parameters*/ 

while (current_time < next_script_time) { 

/*if the current time is less than the next script line*/ 

if (script_entity. alive != FALSE) { 

/♦Apply the script line, if the entity is alive*/ 
entity array [script entity. id] = script entity; 

} 

/♦read the script file*/ 

read (scriptfile, next_script_time, script_entity) ; 

} 

} 



Figure 73. Script Playback Algorithm 

entity positions between PDU updates. Dead reckoning is discussed in detail in "DEAD RECKONING". 
Much like the scripted entities, the network entities receive periodic updates from some source and are dead 
reckoned between the updates. Unlike the scripted entities, there is no way of knowing when the next update 
is coming or where the entity will be located when the update arrives. This places even more importance on 
the dead reckoning algorithm. The issue of network latency can become a problem over long haul or saturated 
networks. To minimize the latency, all pending messages are applied to the entities during each frame. This 
ensures that the system is operating with the most current data possible. 

D. SUMMARY 

The combination of noise, scripted, networked, and user controlled entities has contributed greatly to 
the success of NPSNET. When the system is brought up in the single user mode, the user always asks where 
the other players are. This stems largely from human nature. We are social creatures and enjoy the interaction 
with other people, or at least what we perceive as other people. By combining the computer generated forces 
(CGF) and the human controlled entities in a controlled manner, it presents a challenge to the user to deter- 
mine which of the entities are live and which are CGF. This increases the user’s belief that the world contains 
more people in it than it actually does. As mentioned above, having a large population is a key requirement 
in a VW. The requirement is further modified, in the case of NPSNET, to ensure a large realistic behaving 
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population. As we presented in this chapter, the entities that make up population can come from several dif- 
ferent sources, as long as to the user they appear to be human controlled. 
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IX. SCENE MANAGEMENT 



As discussed previously, the primary function of the scene management process is the selection of the 
polygons to be passed to the rendering process. The view volume, also known as the viewing frustum, is that 
part of the VW that is visible to the user from the current eyepoint. It is defined by the near and far clipping 
planes and the vertical and horizontal field of views. Figure 74. In this chapter, we discuss how the view vol- 
ume is constructed and used to select the polygons that are the pertinent parts of the database. Once the parts 
of the database that are in view are selected, the scene management process determines if it is possible to re- 
duce the level of detail (LoD) of the representation of the features in the database without affecting the scene 
quality. The creation of a view volume and LoD processing, combine to reduce the number of polygons 
passed to the rendering process. The catch with this process is that the elimination of polygons from the scene 
must take less time than rendering them. If it takes longer to cull than to render, it makes no sense to do the 
culling at all. 
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